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PREFACE 


This  report  is  one  in  a series  of  guidebooks  intended  to  help  Program 
Office  personnel  in  software  acquisition  management.  The  contents  of  the 
guidebooks  will  be  revised  periodically  to  reflect  changes  in  software 
acquisition  policies  A practices,  and  feedback  froa  users. 

This  guidebook  has  been  prepared  under  the  direction  of  the  Electronic 
Sys teas  Division  (ESD),  Air  Force  Systems  Conan nd  (IF SC} , Computer  Systeas 
Engineering  Directorate  (hCI) . Contributions  were  aade  by  the  following  ESD 
personnel:  Major  Lee  Burner  (DRT)  and  Captain  W.  .7.  kbits  (MCI)  (Project 

Officer) . 

The  Software  Acquisition  Manageaent  Guidebook  series  is  currently  planned 
to  ccver  the  following  topics.  (Rational  Technical  Information  Service 
accession  numbers  for  those  already  published  are  in  parentheses). 

1.  Project  Guide  to  Content  Requirement  and  Audience  Reeds  (AD-A01912*) 

2.  Regulations,  Specifications  A Standards  (AD-A016A01) 

3.  Contracting  for  Software  Acquisition  (AD-A020AM) 

A.  Monitoring  and  Reporting  Software  Development  Status  (AD-A016A&3) 

5-  Statement  of  Work  Preparation 

6.  Reviews  and  Audits 

7.  Configuration  Manageaent 

3.  Requirements  Specification 

9.  Software  Documentation  Requirements  (AD-A02705D 

1C.  Verification 

IT.  Validation  and  Certification 

12.  Overview  of  the  S-ries 

13.  Computer  Program  Maintenance 

It.  Software  Quality  Assurance 

15.  Software  Cost  Estiaating  and  Measuring 

16.  Software  Development  and  Maintenance  Facilities 

17.  Life  Cycle  Events 
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1. 


imrsoDucTioii 


This  guideoock  explains  the  preparation  of  Statements  of  Work*  (SCV.t)  and 
describes  other  components  of  Requests  for  Proposal  (PFPs)  for  acquisition  of 
Electronic  Systems  that  comprise,  or  include,  software  (i.e.,  comprtor 
programs,  computer  data  bases  anti  their  documentation).  Electronic  System? 
are  one  of  seven  types  of  system  identified  in  KIL-STD-35 'A , tfgrjk  ^r»»krtnwr> 
Structures  for  Defense  Materiel  Items.  % substantial  numter  of  ESB-managed 
systems  are  Electronic  Systems. 

A RrP  is  a formal  document,  sent  to  each  of  a list  of  prospective 
contractors,  which  describes  a group  or  supplies  or  services  to  be  procured 
from  industry  under  negotiated  Procurements” , outlines  terms  and  conditions 
acceptable  to  the  Government,  and  solicits  proposals  consistent  with  this 
information.  Tr.e  companies  that  submit  proposals  are  termed  Offerers.  The 
SOU  is  that  part  of  a RF?  which  describes  the  scope  of  the  work  that  this 
Government  wants  done  by  the  selected  contractor.  Other  parts  of  the  RIP?  of 
particular  software  relevance  are  the  Guidance  to  Offerers;  the  Proposal 
Evaluation  Criteria;  the  Government-oroposed  contract  terms  and  conditions; 
the  Delivery  Schedule;  the  Contract  Data  Requirements  List  (CDP.L);  and  ixxst 
important , the  Specifications,  which  define  what  is  to  be  built  or  bought. 
After  possible  change  during  contract  negotiations,  the  SOW,  the  Delivery 
Schedule,  the  CDRL  and  the  Specifications  become  part  of  the  contract  with  the 
winning  Offerer,  and  th'is  spell  out  the  obligations  of  both  Government  and 
contractor. 

1.1  gmraas 

The  guidebook  has  been  prepared  for  use  by  Air  Force  Program  Office  (PO) 
personnel  in  general  and  a person  termed  the  Software  Director  in  particular. 
The  Software  Director  is  the  military  officer  or  civilian  within  the  Frog ram 
Office  who  assists  the  Prog ran  Manager  (PM)  in  planning  and  managing  software 
development  activities.  As  such,  the  Software  Director  is  one  member  of  an 
Air  ?'  ce  program  management  team  that  includes  technical,  procurement,  legal, 
data  management,  configuration  management,  and  other  specialists  whose 
ccmoined  efforts  are  necessary  for  the  successful  completion  of  an  acquisition 
program.  Different  individuals  (e.g.,  the  Engineering  Division  director)  say 
perform  the  Software  Director's  functions  in  different  Program  Offices,  or 
these  functions  ray  be  split  among  different  persons.  However,  with 
appropriate  compensation  for  such  variations  in  organization,  this  guidebook's 
contents  apply  unchanged. 

Unlike  a directive,  this  guidebook  does  not  prescribe  what  must  be  done. 
Instead,  it  identifies  issues  and  pitfalls;  references  relevant  sections  of 


• The  guidebook  capitalizes  specialized  terminology.  See  Section  1.3. 

l*  Paragraph  2-3-1  of  ESD-TR-75-365,  An  Air  Force  Guide  to  Contracting  for 
Software  Acquisition,  explains  Negotiated  Procurements  vs.  Formally 
Advertized  Procurements.  The  latter,  which  require  completely  detailed 
specifications,  are  inappropriate  for  typical  software-related  system 
acquisition. 

tocofa*  psft  fata* 
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appropriate  Regulations,  Specifications  and  Standards;  and  suggests 
alternative  approaches.  Any  questions  that  say  arise  over  the  feasibility  or 
legality  of  suggestions  made  herein  should  be  referred  for  decision  to  the 
Program  Manager  or  to  the  appropriate  Procuring  Contracting  Officer  (PCO). 

Existing  Regulations,  Specifications  and  Standards  define  no  special 
types  of  SCW  or  RF?  for  software  development.  Also,  software  and  equipment 
follow  similar  acquisition  processes,  nevertheless , there  are  significant 
differences  between  systems  that  include  software  development  and  those  that 
do  not.  These  differences  should  be  reflected  during  preparation  of  SOtis  and 
other-  P.F?  cosponents.  For  example,  the  replication  of  software,  unlike 
equipment,  entaii3  so  aanufacture.  Again,  the  relative  ease  of  incorrect  and 
hard  to  trace  software  aodif icaticn  requires  special  emphasis  on  control  of 
computer  program  Versions  (see  Section  C2.1.1).  This  guidebook  attempts  to 
highlight  these  differences  and  their  implications. 

1.2  Scope 

The  guidebook  introduces  software-related  SOW  preparation  for  Electronic 
Systems  acquired  within  the  framework  cf  the  800-series  of  Air  Force 
regulations  and  manuals.  The  600-series  covers  the  research,  design, 
development,  engineering,  testing,  and  production  of  tactical  A strategic 
systems  for  the  operational  inventory.  The  800-series  normally  governs 
acquisition  of  computers  and  software  which  are  embedded  in  a weapons  or 
ccossand  and  control  systea.  Some  of  this  software  (e.g.,  Application 
Programs)  may  be  built  expressly  for  the  weapons  or  command  and  control 
systea.  Seme  (e.g.,  certain  Operational  Executives)  say  be  codified  versions 
of  off-tne-shelf  software.  A third  subset  (e.g.,  Compilers,  Assemblers)  may 
consist  of  unaltered  off-the-shelf  software.  In  contrast,  the  acquisition  of 
cff-the-shelf , commercially  marketed  data  processing  equipment  and  its 
associated  support  ( “ non- functional”)  softuc*^=  for  busine3s-Iike  applications 
(e.g.,  payrolls,  logistics,  personnel  records,  lanagement  reporting)  is 
normally  governed  by  the  300-series  of  Ai"  Force  regulations  and  manuals. 
(ESD-TR-75-9’ , Software  Acquisition  Management  Guidebook:  Regulations, 
Specifications  arvu  Standards.  Chapter  2,  further  compares  the  300-series  and 
the  600-seriesi.  This  SOW  guidebook  does  not  address  acquisitions  managed  in 
accordance  with  the  300-scries,  although  its  principles  may  apply  there  and 
elsewhere . 

The  guidebook  emphasizes  preparation  and  review  of  softvare-rslated  SOW 
material  for  the  Full-Scale  Development  Phase*  of  major  Command,  Control  and 
Communication  systems  that  include  software,  equipment  and  other  components. 
This  type  of  SOW  is  illustrated  and  discussed  because  it  is  usually  more 
complex  than  any  other,  and  because  the  effects  of  errors  and  omissions  in  the 
procurement  packages  for  Full-Scale  Development  of  sjch  Major  Defense  Systems* 
are  typically  very  costly.  However,  software-related  matters  that  should  be 
considered  during  preparation  of  Conceptual  Phase*  and  Validation  Phase*  SCWs 
are  addressed  throughout  the  guidebook. 

• Software  Acualsltion  Manage.  cnt  Guidebook:  Life  Cycle  Events  ( LCEG ) 

explains  Major  Defense  Systeas,  their  Acquisition  Life  Cyrle  phases,  and 

the  Computer  Progras  Life  Cycle  Phases  of  the  software  they  involve. 


10 


This  guideoock  emphasizes  SC%'  preparation  sore  than  oost  other  aspects  of 
RFP  development  because  the  latter  typically  encounter  fewer  software-peculiar 
problems.  Consequently,  existing  general  guidance  for  RFP  preparation* 
requires  relatively  little  augmentation . However,  overall  RF?  structure,  CDRL 
contents,  and  some  aspects  of  the  .Specifications,  are  discussed  in  scee  depth, 
because  of  their  close  relationships  to  SOW  preparation.  As  a rule,  the 
guidebook  avoids  duplicating  material  found  in  the  readily-accessible 
documents  that  it  references.  Instead,  it  provides  a framework  for  their  use 
with  specific  emphasis  on  software. 

1 - 3 Conventions 

The  Regulations,  Specifications  and  Standards  on  which  this  guidebook  is 
largely  based  use  many  terms  drawn  from  ordinary  English  in  special  ways. 

These  directives  define  acronyms  for  sore  of  these  terms  but  not  for  others. 
Where  acronyms  are  used,  they  help  make  clear  the  special  meanings  intended, 
but  where  no  acronym  :a  used  confusion  ray  arise.  To  minimize  this  problem  in 
the  guidebook,  terms  used  in  special  ways  are  capitalized.  These  special 
terms  are  usually  defined  in  the  guidebook  section  where  they  first  occur,  in 
references  cited  there,  or  in  the  Life  Cycle  Events  guidebook.  The  guidebook 
uses  acronyms  in  censor,  parlance,  and  certain  others  for  brevity.  Each  is 
defined  where  first  used,  and  repeated  in  the  List  of  Abbreviations. 

Readers  can  distinguish  the  direction,  advice,  and  other  options 
interspersed  in  the  guidebook  by  noting  the  following  conventions.  To 
designate  mandatory  action  (e.g.,  action  prescribed  by  applicable  Regulations, 
Specifications  and  Standards),  the  guidebook  employs  'must"  or  "shall*.  In 
contrast,  "should*  cr  "it  is  recommended  tnat",  identify  action  recommended  by 
the  authors,  while  "may*  and  "might"  connote  other  optional  actions. 

!.*s  Plan 

Section  2 treats  planning  for  SOU  preparation,  emphasizing  the  actions 
required  for  SCU  development  and  approval,  and  a SOU's  relation  to  the  other 
components  of  the  RF?.  Section  3 contains  mod e 1 Full-Scale  Development  Phase 
SCU  paragraphs  that  prescribe  software-related  work,  and  commentary  on  these 
paragraphs.  Appendices  A-C  discuss  other  topics  closely  re la tea  to  SOW 
preparation:  Work  Breakdown  Structures  (WBSs),  the  Source  Selection  Plan,  and 

otner  portions  of  the  RF?.  The  guidebook  also  includes  a List  of 
Abbreviations  and  a list  of  pertinent  references. 


Especially  ArSCP  ‘r3--.  Request  for  F reposal  Preparation  Guide. 
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1.5  How  to  Use  this  Guidebook 


Use  of  the  SOW  guidebook  in  two  wain  ways  is  anticipated : 

a.  as  a tutorial  on  SOW  preparation  for  persons  relatively 
inexperienced  in  the  acquisition  of  large  systems  that  include 
software ; 

b.  as  an  introduction  to  the  mechanics  of  software-related  SOW 
preparation  for  those  otherwise  quite  familiar  with  the  acquisition 
of  large  systess. 

The  first  type  of  *iser  should  first  review  thoroughly  the  Life  Cycle 
Events  guidebook  CLCBG).  Section  2 of  the  SOW  guidebook  should  then  be  read, 
with  excursions  through  Appendices  A-C  as  each  is  first  referenced.  Finally, 
Section  3 should  be  studied  as  a realistic  SOW  model  in  the  light  cf  this 
background. 

The  second  type  of  user  should  at  least  scan  the  Life  Cycle  Events 
guidebook,  with  special  attention  to  its  tables,  as  a compact  source  of 
information  about  Acquisition  Life  Cycle  and  Computer  Program  Life  Cycle 
events,  activities  and  products  that  should  be  considered  In  composing  his 
SOW.  This  type  of  user  should  then  use  Section  3 of  the  SOW  guidebook  as  a 
guide  to  the  SOW  preparation  process,  referring  to  the  Appendices  and  to  the 
oodel  SOW  for  specific  information  needed.  The  rather  extensive  cross- 
referencing  among  the  guidebook's  main  sections  and  appendices  is  intended  to 
facilitate  this  approach. 
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2.  PLANNING  FOR  SON  PREPARATION 


Considerable  planning  by  Government  personnel  must  precede  Major  Defense 
Systea  Validation  Phase  and  Full-Scale  Development  Phase  SOW  preparation. 
First,  the  systec  to  be  acquired  must  be  defined  well  enough  to  permit 
reasonable  assessment  of  the  overall  effort  and  co3ts  involved.  Next,  this 
effort  must  be  roughly  scheduled,  and  the  Government  participants'  roles 
established.  Then  groups  of  tasks  must  be  identified,  for  performance  by 
contractors.  A similar  group  of  tasks  for  each  participating  Government 
organization  most  be  defined.  The  basic  procurement  approach  must  be  decided, 
including  whether  the  system  will  be  segmented,  the  number  of  contractors 
desired  and  the  roles  of  each.*  Each  such  group  of  tasks,  and  the  group  of 
Nil  tasks,  must  be  represented  respectively  in  a Preliminary  Contract  Work 
Breakdown  Structure  (Preliminary  CWBS)  and  a Project  Summary  MBS  (see  Appendix 
A),  and  referenced  in  other  planning  documents  (e.g.,  the  Program  Management 
Plan  (PHP),  which  is  written  in  response  to  the  Program  Management  Directive 
(PHD)).  A Source  Selection  Plan  (see  Appendix  5}  mas.  be  prepared  and 
approved.  Finally,  an  RFP  (see  Appendix  C),  including  a SON,  must  be 
developed  for  each  planned  contract,  and  analogous  memoranda  of  agreement  must 
be  worked  out  among  the  Government  participants.  The  narrative  and  tables  in 
LCEG  Sections  2 through  8,  plus  appropriate  directives  referenced  there, 
should  be  consulted  as  a basis  for  these  agreements. 

the  Computer  Resources  Integrated  Support  Plan  (CRISP)  is  an  agreement 
about  computer  resources  among  the  Government  participants.**  It  is  analogous 
to  major  portions  of  the  contract  negotiated  between  the  Government  and  each 
contractor.  The  CRISP  defines  generally  the  work  to  be  dene  by  each 
participating  Government  organization  (e.g.,  a Using  Command  computer  program 
development  group).  However,  this  definition  of  work  allocation  may  not  be 
clear  enough  to  prevent  potential  misunderstandings  about  specific 
responsibilities,  which  are  at  least  as  likely  among  Government  participants 
as  between  Govemaent  and  contractor.  Therefore,  it  is  strongly  recommended 
that  a SCW  specifying  each  Government  participant's  computer-related  work  be 
negotiated  and  made  an  appendix  to  the  CRISP. 

Subsequent  paragraphs  on  planning  for  SOW  preparation  stress  the 
Validation  and  Full-Scale  Development  Phases  of  a Major  Defense  System.  This 
information  may  be  tailored  to  SON  preparation  for  other  Major  Defense  System 
Acquisition  Life  Cycle  phases  and  for  Less-Than-Major  System  acquisitions. 

SO*  preparation  planning  for  other  than  Major  Defense  System  Validation 
Phase  and  Full-Scale  Development  Phase  work  can  be  less  elaborate  (see  LCEG 
Sections  3,  6,  and  7).  In  particular,  a SOW  for  the  initial  definition  of  a 
system  must  necessarily  be  written  in  rather  general  terms.# 


• ESD-TR-75-365,  paragraph  2.2,  diseases  the  major  issues. 

*•  See  LCEG  Section  4.4.2  and  AFR  800-14,  Acquisition  ami  Support  Procedures 
for  Computer  Resources  in  Svstess.  Vol.  II,  paragraph  3-8. 

# E.g.,  see  AFSC?  600-6,  Statement  of  Work  Preparation  Guide.  Chapters  3-5- 
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A SQM  should: 


I 


a.  define  precisely  all  the  none  desired  fro*  the  contractor  (or 
equivalent  Government  organisation)  that  is  not  inherent  in  or 
required  by  any  other  contractual  attachment; 

b.  naae  the  product(s)  of  each  task; 

c.  define  or  imply  no  un wanted  task  or  product; 

d.  reference  the  contract's  Delivery  Schedule  (see  Section  C2-3)  for  an 
appropriate  Period  of  Performance  or  completion  date  for  each  task, 
and  an  appropriate  delivery  date  for  each  product  other  than  Data 
(i.e. , documentation  or  Computer  Programs); 

e.  rely  on  the  CDRL  (see  Section  C2.7)  to  establish  the  fore,  content, 
and  delivery  requirements  for  Data; 

f.  be  consistent  with  the  Preliminary  CUBS  (see  Section  A4.4)  and  the 
CDRL;  and 

g.  be  consistent  with  program  objectives  (e.g.,  as  stated  in  the  PKD). 

Subsequent  subsections  interpret  these  objectives,  state  general  requirements 
for  SOU  p» eparation,  suggest  actions  helpful  to  a good  SOM's  preparation,  and 
provide  guidance  for  definition  of  Configuration  Items  (CIs)  for  Validation 
Phase  contracts.  The  model  Full-Scale  Development  Phase  SQM  paragraphs  and 
related  commentary  in  Section  3 provide  further  guidance.  Some  requirements 
and  other  guidance  stated  elsewhere  in  this  guidebook  are  repeated  here  for 
eas>  reference. 


2.  1 fffe  -e 


The  requirements  stated  below  apply  generally  to  SOWs  for  Validation 
Phase  and  Full-Scale  Development  Phase  contracts.  Where  directed  they  also 
apply  to  SOWs  for  other  types  of  contract. 


2.1.1 


I «rr?  i *>  rn***.. 


Each  SOW  must  correspond  in  structure  and  substance  to  the  planned 
contract's  Preliminary  CWBS  (see  Section  14.4)  to  whatever  depth  the  latter  is 
defined . That  is : 


a.  a separate  SOW  paragraph  must  be  prepared  corresponding  to  each 
?r_-x  It  inary  CWBS  Element; 

b.  each  such  SOW  paragraph's  task  description  must  define  work  consis- 
tent in  scope  with  the  corresponding  Preliminary  CWBS  Element;  and 

c.  each  such  SOW  paragraph  and  the  corresponding  Preliminary  CWBS 
Element  sust  bear  the  same  Prog ran  Breakdown  Code  (PBC)  (see  Section 
13),  and  should  normally  bear  the  same  naae. 


lu 


As  a result,  a SOW  Bust  nave  an  hierarchical  structure  like  a WBS. 

A SCV  uill  normally  define  tasks  is  greater  detail  than  the 
lowest-level  Preliminary  CUBS  Elements.  The  SOW  subparagraphs  defining  these 
tasks  may  be  nested  tc  any  depth.  A contractor  can  and  normally  should  be 
required  to  segregate  and  report  costs  by  the  lowest-level  Extended  CUBS 
Elements  defined.  {See  Section  A*. 6). 

2-1-2  SOW  Paragraph  and  CLIM  Correspondence 

Each  SOW  paragraph  (at  and  above  some  level)  that  prescribes 
contract  effort  must  correspond  to  a CLIk  (i.e.,  a Contract  Line  Item  or 
.ivbiine  I ten)  of  the  same  name  (see  Section  C2.1).  A SOW  paragraph  that  calls 
.or  acquisition  of  a CPCI  must  also  correspond  to  an  Exhibit  CLIM  (see  Section 
C2-1-2).  The  same  CLIM  or  Exhibit  CLIM  nay  correspond  to  more  than  one  CPCI, 
but  1-1  correspondence  is  preferable  (see  Section  C2.1).  Such  correspondence 
is  assured  if  the  Preliminary  CUBS  and  the  SOW  structures  are  coordinated  (see 
Section  A*.*),  and  if  the  CLIM  descriptions  are  based  on  a completed  SOW  (see 
Section  C2-2). 

2*1-3  SOW  Incorporation  of  P3Cs 

Each  Validation  phase  or  Full-Scale  Development  Phase  SOW 
paragraph  that  prescribes  contract  effort  must  be  identified  by  the  PBC  of  the 
corresponding  Preliminary  CWBS  Element.  Each  such  SOW  paragraph  should  also 
be  assigned  an  index  (e.g.,  5*1*1  2)  that  identifies  uniquely  its  position  in 
the  SOW's  hierarchic  structure.  Each  SOW  paragraph  that  does  not  correspond 
to  a Preliminary  CWBS  Element  should  also  be  assigned  an  index,  but  no  PBC. 

For  example.  Exhibit  1 paragraph  5* 1.5*1  corresponds  to  Preliminary  CUBS 
Element  A1061  and  thus  contains  this  PBC.  However,  Exhibit  1 paragraph 
5. 1.5* 1*1  is  a subparagraph  of  paragraph  5- 1*5.1  for  which  no  corresponding 
Preliminary  CWBS  Element  exists.  Thus,  paragraph  5 .1.5. 1*1  contains  no  PBC. 

2.1. A SOW  Paragraph  to  CPCI  Correspondence 

A separate  SOW  paragraph  must  call  for  acquisition  of  each 
Computer  Program  Configuration  Item  (CFCI).  (See  Section  C2.1). 

2.1-5  SOW  Paragraph  to  CDRL  Entry  Correspondence 

Each  Data  Item  (see  Section  C2-7)  to  be  delivered  under  the 
planned  contract  (including  software  storage  media)  must  be  identified  in  a 
CDRL  entry.  This  CDRL  entry  must  define  the  Data  Item  (e.g.,  by  Data  Item 
Description  (DID)  reference)  and,  except  for  software  storage  media,  must 
prescribe  the  terms  for  its  delivery.  The  same  CDRL  entry  may  define  more 
than  one  Data  Item  (e.g.,  several  CPCIs'  Computer  Prognus  Product 
Specifications)  as  long  as  that  CDRL  entry  defines  them  all  correctly  and 
precisely.  In  addition,  one  or  mere  specific  Armed  Services  Procurement 
Regulations  (ASPR)  or  SOW  paragraphs  eust  call  for  the  work  that  results  in 
the  preparation  of  each  Data  Item.  The  CDRL  entry  must  reference  these 
paragraphs  by  paragraph  index  or  PBC.  Both  the  SOW  and  the  CDRL  entry  must 
identify  the  Data  Item  by  the  same  name.  In  addition,  the  SOW  paragraph 
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should  reference  the  Data  I tea  by  name , and  say  reference  the  CDRL  entry  by 
its  sequence  nuaber.  However,  current  ESD  policy*  prohibits  a SOU  paragraph 
from  prescribing  Data  I ten  structure  or  content,  and  fro*  incorporating  a DID 
reference. 

2.1.6  Completion  Dates  and  Periods  of  Performance 

CLIJi  completion  dates  and  Periods  of  Performance  should  be 
included  in  the  Delivery  Schedule  and  referenced  there  fro*  the  SOU 
paragraphs.  Data  Ite*  delivery  dates  aust  be  included  in  CDRL  entries,  except 
that  the  special  CDRL  entry  that  represents  each  CPCI  aust  reference  the 
Delivery  Schedule  for  the  CPCI  delivery  date(s).  (See  Section  C2.1.2  and 
Section  C2-3)-  The  SOU  itself  nay  contain  neither  delivery  dates  nor  Periods 
of  Performance.  This  aandatory  approach  centrates  all  date-related  SOU 
requirements , which  siaplifies  their  jt  ig  and  cross-checking  for 
feasibility. 

2.1.7  Enforcement  of  Proposed  Plans 

A Special  Provision  of  the  contract  (see  Section  C2.5)  is 
necessary  to  require  a contractor  to  follow  a plan  (e.g.,  a System  Engineering 
Management  Plan  (SEKP),  a Coaputer  Program  Development  Plan  (CPDP))  contained 
in  his  proposal.  A SOU  paragraph  should  call  for  updating  each  such  plan,  and 
tnt  CDRL  should  state  its  required  delivery  dates. 

2.2  General  Suggestions  for  SOU  Preparation 

A1 trough  not  requirements,  several  practices  described  below  are 
recomaended  as  aids  to  developing  sound  SOU s. 

First,  those  charged  with  SOU  preparation  should  assemble  and  study  the 
appropriate  background  material  to  be  sure  they  understand  the  system's 
objectives  and  requirements,  plus  the  planned  contract's  objectives.  In 
particular,  tne  latest  Decision  Coordinating  Paper  (DCP)M  (if  any)  and  PHD 
should  be  reviewed  for  objectives  and  specific  direction.  The  PHP  should  be 
studied  to  understand  the  overall  acquisition  management  approach,  and  each 
participant's  role.  The  latest  Project  Summary  V3S  or  Summary  Program 
Breakdown  Structure  (PBS)  (see  Sections  AA.2  and  AA.3),  as  A the  essentials  of 
any  related  contracts,  existing  or  planned,  should  be  reviewed  to  understand 
the  interactions  of  other  progrsoi-related  activities  with  the  planned 
contract.  The  Life  Cycle  Events  Guidebook,  especially  Tables  1-A,  should  be 
examined  as  a source  of  potential  SCU  tasks  and  related  products.  Critical 
milestones  snould  oe  spelled  out  in  a master  schedule.  Finally,  the  other 
portions  of  the  planned  contract's  RFP  (see  Appendix  C)  should  be  understood, 
especially  the  Specifications. 

Second,  a draft  Preliainary  C¥3S  must  be  prepared  (see  Section  A*.*)  and 
(for  ESD-sanaged  programs)  coordinated  with  the  Cost  Analysis  Division  (ACC). 


• ArSCR  3 1 * / ESJD  Sup.  1,  Management  of  Contractor  Data,  paragraph  3-Q  ■ 

••  DCPs  are  prepared  only  for  Major  Defense  Systems.  See  LCEG,  Section  2. 
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Third,  for  ESD-managed  programs,  the  SOU  preparation  task  should  be 
discussed  with  the  Directorate  of  Acquisition  Support  (DR)  to  obtain  current 
information  on  sow-related  policy  and  other  guidance. 

Fourth,  the  latest  versions  of  all  Regulations,  Specifications, 

Standards,  and  DIDs,  whose  application  to  SOW-specified  tasks  and  related  Data 
Items  is  planned,  should  be  reviewed  to  determine  their  applicable  sections 
and  to  decide  on  appropriate  modifications.  As  a rule.  Air  Force  and  lower 
level  command  regulations,  manuals,  and  pamphlets  should  not  be  referenced  In 
a SOU.  However,  this  rule  nay  be  overlooked  whenever  it  would  entail 
incorporating  voluminous  material  explicitly  in  the  SON.  (e.g. , see  model  SOU 
paragraph  3).  Military  specifications  and  standards  nay  be  freely  referenced. 
Specific  and  appropriate  references  are  essential  to  clear,  precise,  and 
appropriate  SOU  task  descriptions.  Similarly,  understanding  the  applicable 
DIDs  is  essential  to  relevant  Data  Iter  definitions.  SOU  and  CDRL  references 
that  are  too  broad  risk  misinterpretation  of  the  scope  of  effort  and  products 
desired.  On  the  other  hand,  SOU  and  CDRL  provisions  that  restate  requirements 
contained  in  the  System  Specification,  in  Development  Specifications,  or  in 
appropriate  Regulations,  Specifications,  Standards  or  DIDs  risk  inconsistency 
and  entail  parallel  updating. 

Fifth,  previously  prepared  SOUs  and  related  CDRL  entries  should  be 
acquired  and  their  relevant  paragraphs,  if  any,  considered  as  models  for 
related  tasks  under  the  planned  contract.  However,  these  model  SOU  paragraphs 
and  related  CDRL  entries  should  be  reviewed  critically,  screened!,  and 
carefully  modified  to  avoid  including  in  the  planned  contract's  SOU 
inconsistent,  excessive,  and  otherwise  inappropriate  provisions.  These  model 
SOUs  and  CDRL  entries  should  be  discussed  with  persons  familiar  with  their 
contracts'  performance  histories,  to  reveal  any  problems  attributed  to 
defective  SOU  provisions.  The  Model  Full-Scale  Development  Phase  SOU 
paragraphs  in  Section  3 a re  one  source  of  possibly  '•elevant  SOU  aaterial. 

ESDn  80C-A,  Statement  of  work  Preparation  Guide.  Change  1,  is  another  source. 
This  contains  52  short  sections  on  different  potential  SOW  tasks.  Each 
section  includes  model  SCW  paragraphs,  suggestions  for  preparing  such 
paragraphs,  or  both.  Table  1 shows  these  tasks'  titles  4 PBCs,  and  assesses 
the  usual  relevance  of  each  to  so ft ware- re la ted  SCW  preparation.  4s  Table  1 
states,  tasks  deeaed  irrelevant  or  only  marginally  relevant  to  software  should 
be  considered  nore  relevant  if  their  acconplishsent  should  require  software. 
For  example,  if  a system's  Support  Equipment  included  software-controlled 
Automated  Test  Equipment,  the  Support  Equipment  SOU  task  would  be  of  primary 
importance  to  the  Software  Director. 

Sixth,  experts  on  particular  types  of  desired  effort  or  products  should 
be  consulted  about  the  related  SCW  paragraphs  and  CDRL  entries.  If  possible, 
these  persons  should  prepare  initial  drafts  of  the  SCA?  paragraphs  and  related 
CDHL  entries  in  their  areas  of  expertise,  using  or  adapting  model  SCW 
paragraphs  where  appropriate.  Corresponding  SOU  paragraphs,  and  proposed  CDS! 
entries,  should  always  be  prepared  in  parallel.  Special  CDRL  entries  must 
specify  tne  delivery  of  CPCls  and  their  Versions  (see  Section  C2.1.2). 

Seventh,  a saall  group  of  key  Program  Office  personnel , including  the 
Software  Director,  should  review  these  drafts,  alter  them  appropriately,  and 
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Table  1 


NORMAL*  SOFTWARE  RELEVANCE  OF  POTENTIAL  SOW  TASKS 


ESDP  Software 
800-4  Relevance 


SOW  Task  Title** 

1&SJQEX25 

fKM 

Aerospace  Environment 

9 

I 

106  IE 

Availability 

40 

p 

106  IQ 

COeaunications  Long  L les 

15 

I 

106 1H 

Computer  Program  Moo  sent# 

2 

p 

4210 

Configuration  Management 

22 

p 

10&2C 

Program/ Con tract  Work  Breakdown  Structure 

20 

p 

1062AA 

Cost  Information  Systeisv 

18 

s 

1062AB 

Cost/Schedule  Control  System# 

19 

p 

1062AC 

Data  Management# 

35 

s 

1070 

Design,  Development  and  Fabrication# 

4 

p 

1010 

Electromagnetic  Compatibility 

11 

I 

1061G 

Hunan  Factors  and  Training# 

3* 

s 

1C64,  1 

Integrated  Logistics  Support 

27 

M 

1063 

Initial  Spiire/Repair  Parts  Provisioning# 

38 

I 

9600 

Integration  of  Analyses  and  Related 
Computer  Support 

39 

S 

1062D 

Life  Cycle  Costa 

ASPR 

S 

1062AD 

Maintainability 

6 

P 

1061B 

Manufacturing  Management 

21 

I 

1062B 

Jfcoenclature 

8 

M 

1061D 

Parts  Control  A Standardization  Program# 

7 

M 

1061C 

Pnotographic  Documentation 

25 

I 

1062F 

Preoperationai  Maintenance# 

32 

M 

106  3E 

Preoperational  Supply  Support 

28 

I 

106  §A 

Preservation,  Packaging,  Packing  A Narking#  29 

S 

106 3B 

Cuality/Progras/Inspection  System# 

24 

P 

1062E 

Radio  Frequency  Management 

15 

I 

1061N 

Seal  Property  Facilities# 

37 

I 

1082 

Reliability 

5 

P 

1061A 

Schedule  Management 

17 

P 

1062AE 

Security 

12 

s 

1061J 

STIKFO 

26 

M 

1062G 

Support  Equipsent# 

33 

M 

9200 

Sunrivahility/Vulnerability 

*3 

S 

1061K 

System  Engineering  Management # 

3 

P 

1061 

System  .Safety 

14 

S 

106 1L 

Technical  Orders# 

36 

P 

1071 

Test  and  -valuation# 

t 

P 

1050 

Trans porta b i 1 i ty 

10 

I 

1C61F 

Transportation 

30 

I 

106 30 

Travel 

31 

I 

10630 
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Table  1 (Concluded) 


ESDP 

eoo-k 

Software 

Melevance 

SM  Task  Title— 

l£aS5i 

ISsslJEDI 

am 

Vslue  Engineering  - Program 
acquirements  Clause# 

23 

p 

1061P 

F*lu*  Engineering  . Incentive 
Program  Clause# 

3 

s 

1061 

IB 

I * Irrelevant 

H s Marginal.  However,  the  Software  Director  should  review  this  task 
statement  to  avoid  surprises. 

S = Substantial.  The  Software  Director  should  influence  and  coordinate 
on  this  L*sk  statement  to  assure  consistency. 

P s Primary.  The  Software  Director  should  prepare  the  software-related 
Sections,  and  should  review  the  entire  task  statement,  as  a natter 
of  -rime  concern. 


• Homily  irrelevant  (I)  or  marginally  relevant  (M)  task  descriptions 
(see  KEf)  should  be  carefully  reviewed  and  coordinated  by  the  Software 
Director  if  their  accomplishment  entails  the  use  or  development  of 
software. 

*•  Per  ESDP  80u-A  (Change  1),  Attachment  1. 

# This  title  differs  frcm  the  Standard  MBS  Element  Marne. 

See  Table  A-1. 

##  Prefix  this  code  by  the  letter  code  (i.e.,  A,B,...)  for  the  source 
of  the  product  or  service,  if  known.  See  AFSCM  1Y3-*.  Program 
Breakdown  Structure  and  Codes,  paragraph  3-3*  and  Figure* 

5-3  through  5-8. 
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compile  the*  into  an  integrated  5GM  and  proposed  CDIL  consistent  with  the 
Preliminary  CUBS.  This  group  should  assure  the  SOM's  precisions, 
completeness,  internal  consistency,  and  consistency  with  the  other  8FP 
sections.  Elimination  or  alteration  of  CDtL  entries  by  the  Data  Requirements 
Review  Board  (see  Section  C2-7)  may  entail  SOM,  Preliminary  CUBS,  and  other 
RFP  modifications,  to  retain  consistency  and  to  assure  that  the  RFF  continues 
to  satisfy  program  goals.  For  BSD-managed  programs,  coordination  of  the 
complete  SOU  draft  with  the  Directorate  of  Acquisition  Support  (DR),  and  with 
the  Computer  System  Engineering  Directorate  (MCI) , is  required.  If,  during 
SOU  preparation,  changes  to  the  draft  Preliminary  CUBS  are  deemed  desirable, 
these  must  be  coordinated  with  the  Cost  Analysis  Division  (ACC). 

2-3  Configuration  Item  (Cl)  Definition 

SO Us  for  Full-Scale  Development  Phase  contracts  Mist  reflect  the  system's 
Cl  definition  incorporated  in  the  Allocated  Baseline,  which  is  the  major 
Validation  Phase  product  (see  LCBG,  Section  k.3.1).  However,  a SOU  for 
Validation  Phase  work  may  need  to  Include  a Cl  definition  task,  which  should 
yield  as  Authenticated  System  Specification,  and  a Development  Specification 
for  each  of  the  system's  CIs  to  be  developed.  The  following  is  provided  as  a 
partial  aid  to  drafting  this  task  statement. 

The  nunber  and  composition  of  a system's  CIs  is  a critical  design  issue, 
because  the  Government's  technical  monitoring  activities  focus  mainly  on  CIs. 
For  example,  each  CPCI  developed  normally  requires  the  developer  to  prepare  an 
individual  Computer  Program  Product  Specification  (see  LCEG,  Section  Ak),  an 
individual  Test  Plan,  and  related  Test  Procedures.  Each  Cl  usually  undergoes 
individual  design  reviews.  One  or  more  UBS  Elements  (see  Appendix  A)  must 
also  be  defined  for  each  Cl,  for  use  in  cost  reporting  and  analysis. 

A system  of  many  CIs  has  many  formally  defined  interfaces.  The  separate 
reports,  other  documents,  and  other  monitoring  activities  required  can  support 
good  Government  visibility  into,  and  control  of,  the  development  process. 

However,  if  a system  is  partitioned  into  too  many  CIs,  the  large  nuaber 
of  document  review,  Engineering  Change  Proposal  (ECP)  processing,  and  other 
monitoring  activities  entailed  may  fragrent  insight  and  cause  excessive 
delays,  sign!: .cantly  impeding  development  prog, ’■ess.  Independent  or 
sequential  Government  monitoring  of  individual  CIs  may  partly  ignore  the  needs 
of  closely  related  CIs,  sc  that  decisions  made  about  one  Cl  may  adversely 
affect  another.  Conducting  joint  design  reviews  for  the  merntcm  of  each 
closely  related  set  of  CIs,  and  employing  the  same  Government  personnel  to 
monitor  all  the  set's  members,  can  improve  overall  visibility,  nevertheless, 
even  thorough  design  review  rarely  prevents  subsequent  discovery  of  some 
necessary  changes  in  Cl  scope  or  external  Cl  interfaces.  Such  changes  require 
formal  ECF  preparation  and  Configuration  Control  Board  (CCB)  action  during 
development,  activities  that  typically  consume  weeks  or  mcnths . largely 
because  of  its  greater  quantity  of  baselined  information  (eg.,  inter-CI 
interface  definitions  in  Development  Specifications) , a multi-CI  system  may 
require  more  ECPs  during  its  development  than  a system  of  fewer  CIs. 

Similarly,  Use  effort  needed  to  review  and  coordinate  revisions  to  Product 
Specifications,  Test  Plans,  Test  Procedures  and  other  required  documents 
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depends  significantly  on  tie  amber  cf  documents  reviewed  as  well  as  on  the 
scope  of  each.  Like  ECP  processing,  docment  review  can  entail  long  elapsed 
times,  because  consents  nust  typically  be  solicited  fron  nany  reviewers, 
formally  coordinated,  and  reflected  in  one  or  aore  revisions  before  approval. 
Thus,  a eulti-CI  system's  development  nay  suffer  nore  delay  froo  Government 
monitoring  activities  than  a system  of  fewer  CIs. 

Somewhat  different  problems  can  arise  if  a system's  CIs  are  few,  but  ill- 
defined.  This  situation  exists  to  the  extent  that  one  Cl  contains  processes 
that  interact  more  strongly  with  other  CIs  than  with  one  another.  A system  of 
ill-defined  CIs  is  most  likely  when  Cl  definition  occurs  hastily  without 
adequate  preliminary  design  and  design  validation  1 see  LCEG,  Section  A. 3 .2). 
Here  the  inter-CI  interfaces,  although  few,  ?re  complex.  As  a result,  the 
larger  scope  of  the  individual  Cl  design  review  will  still  fail  to  spot  many 
inconsistencies  among  CIs.  Also,  the  complex  internal  workings  of  large,  ill- 
defined  CIs  discourages  learning  and  discovery  of  internal  flaws.  Both 
factors  encourage  overlooked  design  errors  during  document  study  and  design 
reviews.  These  oversights  lead  later  to  many  ECPs  and  to  progressively  more 
expensive  repairs,  depending  on  when  each  error  is  detected. 

Ue  know  of  no  well-defined  procedure  to  specify  an  optimum  set  of  CIs. 
Bcwever,  the  guidelines  stated  below  should  help  define  a good  set  of  CPCIs, 
although  they  are  incomplete. 

a.  Assign  processes  that  interact  strongly  (e.g.,  in  many  or  complex 
ways)  to  the  same  CPCI. 

b.  Assign  processes  with  little  or  no  interaction  to  different  CPCIs. 

c.  Allocate  to  different  CPCIs  processes  that  will  execute  in  different 
computers . 

d.  Assign  to  different  CPCIs  processes  whose  development  can  feasibly 
be  finished  at  significantly  dif* . rent  times,  if  such  phased 
development  will  expedite  overall  system  development. 

e.  Allocate  tc  different  CPCIs  software  to  be  separately  procured. 

f.  Include  in  each  CPCI  no  more  than  an  individual  Government  monitor 
can  efficiently  track,  assuming  reasonable  working  relationships 
between  hi*  and  the  types  of  personnel  who  will  manage  and  develop 
the  CPCI. 

It  should  be  cicar  that  applyir^  these  guidelines  entails  much  preliminary 
design  and  analysis.  Guidelines  a,  b,  d,  and  f cay  also  apply  to  equipment 
CIs,  as  does  guideline  e if  "equipment"  is  substituted  for  "software". 

Even  when  a systes  hau  many  small  CIs,  MBS  definition  aost  generally 
extend  below  the  Cl  level,  to  the  Coaputer  Program  Component  (CPC)  or  major 
routine  level,  in  order  to  yield  data  adequate  for  both  thorough  contractor 
performance  aonitoring  arid  to  sound  future  software  cost  estimation.  Such 
detailing  of  ¥BS  Elements  below  the  Cl  level  is  best  done  by  the  development 
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organization,  with  Pr ogram  Office  concurrence.  It  should  be  done  as  the 
detaiiled  design  of  each  Cl  unfolds,  and  incorporated  in  the  Extended  Contract 
UBS  (see  Section  AO. 6.1. 

One  common  error  in  systea  definition  is  failure  to  specify  as  CPCIs 
certain  essential  Support  Software  (e.g..  Executive,  equipment  and  software 
diagnostics , software  development  and  aaintenance  aids,  test  drivers,  test 
data  generators,  data  collection  and  data  reduction  prograas)*.  As  a result, 
the  Government  aay  lack  noraal  control  of  and  visibility  into  this  software's 
functional  A design  characteristics,  and  aay  even  lack:  the  right  to  use  the 
software  throughout  the  systea 's  lifetime.  Such  rights  of  control,  visibility 
ana  permanent  use  can  be  critical;  e.g.,  to  validating  test  results,  to 
testing  Deployment  phase  software  aodifications.  If  use  of  proprietary 
Operational  or  Support  Software  is  planted,  the  Computer  Prcgraa  Development 
PJian  (see  LCEG,  Section  4. A. 5)  should  detail  its  use  in  the  systea. 
Furthermore,  the  appropriate  contract  should  specifically  provide  for  delivery 
of  that  proprietary  software  with  satisfactory  documentation  and  rights  of 
duplication  A use  (see  Section  C2. 5-4). 

Another  coaaon  error  is  failure  to  prescribe  precisely  the  systea 's 
interfaces  with  its  operators  (e.g.,  terminal  users).  These  interfaces  should 
be  considered  requirements , not  design  options,  because  a good  man-machine 
interface  is  quite  heavily  influenced  by  detailed  operational  requirements. 

Special  problems  may  arise  when  use  is  planned  of  existing  software 
(e.g.,  the  Executive,  a compiler,  diagnostics)  that  was  developed,  perhaps  for 
commercial  use,  independent  of  standard  Air  Force  configuration  control, 
testing  and  docucentation  practices.  Although  incorporating  such  software, 
where  appropriate,  may  save  significant  development  tioe  and  cost,  this 
so! .ware  or  its  documentation  may  be  soaewhat  deficient  for  the  intended  Air 
Force  application.  Thus,  during  the  Validation  Phase,  all  such  existing 
software  should  be  tested,  and  its  documentation  reviewed,  against  system 
requireeents . Plans  should  then  be  made  to  upgrade  or  augment  this  software 
and  its  documentation  during  the  Full-Scale  Developoent  Phase,  to  correct 
deficiencies.  For  example*  if  use  of  a commercially  available  Executive  is 
planned,  this  Executive  should  be  allocated  functional,  design,  interface, 
performance  and  test  requirements.  The  Executive  should  then  be  tested  for 
ability  to  satisfy  all  its  allocated  requirements.  Again,  the  Executive's 
documentation  should  be  reviewed  against  the  needs  of  the  planned  Air  Force 
systea 's  operators,  development  programmers,  and  maintenance  programmers  to 
assure  its  satisfactory  organization  and  content.  Existing  commercial 
documentation  need  not  conform  precisely  to  Air  Force  documentation  standards 
(e.g.,  for  Type  B5  and  Type  C5  specifications  per  MIL-STB-490,  Specification 
Practices  and  HIL-ST£-483(USAF) , Configuration  Etenagement  practices  for 
Systems.  Equipment.  Munitions,  and  Computer  Programs.  However,  these 
standards  should  be  reviewed  for  factors  appropriate  to  judging  existing 
documentation  against  expected  needs.  Note  that  the  Government  may  need  to 
acquire  Liaited  lights  to  this  existing  software,  and  Restricted  Rights  to  its 
documentation  (see  Section  C2.5.4)  in  order  to  use  or  upgrade  them. 


* Table  i-3  identifies  sany  such  types  of  Support  Software. 
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3-  MODEL  FULL-SCALE  O -fELOPKeVT  PHASE  SOV  TASKS 


Section  3 incorporates  a table  of  contents,  and  the  software-related 
paragraphs,  of  a hypothetical  Full-Scale  Development  Phase  SOU . This  SOU  is 
presumed  to  prescribe  the  work  desired  from  a single  contractor  (at  the  system 
level)  to  develop  a postulated  one-of-a-kind  digital  communications  message 
switch,  termed  the  Central  Distribution  S]rs ten  (CDS).  The  SOU-prescr  >ed 
tasks  include  interfacing  the  CDS  with  numerous  local  and  remote  digital  data 
sources  and  sinks. 

Since  the  hypothetical  planned  contract  covers  site  activation,  support 
equipment,  administrative  data,  etc.,  as  well  as  software  acquisition, 
computer  equipment  acquisition,  systems  engineering,  etc  , some  of  the  SCM 
paragraphs  are  either  irrelevant  or  only  marginally  relevant  to  the 
development  of  software  and  its  integration  into  the  total  system.  The  model 
SOU  includes  the  headings  of  such  SOU  paragraphs,  but  nay  not  include  their 
text.  Other  paragraphs  with  soretixes  significant  software  impact  are 
represented  either  by  skeleton  text  or  by  complete  text.  In  the  skeleton  text 
dots  (i.e.,  "...")  replace  each  missing  sequence  of  words  which  are  deemed 
irrelevant  or  o&ly  marginally  relevant  to  software.  The  SOU  paragraphs  sost 
important  to  software  are  incorporated  in  full  and  are  also  asterisked. 

Th  uel  SOW  paragraphs  refer  to  certain  other  documents  (e.g.,  the 
CDRL,  Uk  ' ' ftinary  CUBS  Dictionary  (see  Section  A3),  specifications),  which 
tne  RrP  eonUt-ning  the  SCU  would  normally  include.  Development  of  models  of 
these  documents  has  been  beyond  the  scope  of  this  guidebook's  preparation 
effort.  However,  Section  3 partly  compensates  for  their  lack  by  stating  the 
model  SOM's  chief  assumptions,  and  by  including  other  relevant  background 
material . 

Table  2 depicts  the  Specification  Tree  (normally  part  of  the  System 
Specification)  for  the  hypothetical  CDS.  The  CDS  is  presumed  to  connect  about 
25n  local  and  remote  data  sources  and  sinks,  ranging  from  low-speed  terminals 
tn rough  computers.  Table  2 includes  15  CPC Is  for  three  computers,  in  part  so 
that  the  model  SOU  paragraphs  can  address  multip  * CFCI,  multiple  Functional 
Area,  and  multiple  software  source  issues.  In  practice,  defining  fewer  CFCIs 
eight  be  advantageous , as  discussed  iu  Section  2-3-  However,  distinct  real- 
time vs.  off-line  Executives  would  still  be  desirable  for  a system  like  the 
CDS,  unless  the  off-line  Executives  were  shown  able  to  support  adequate  real- 
time response  times.  Figure  1,  "Central  Distribution  System  Functional  Block 
Diagrax",  shows  the  CDS  Functional  Area  interfaces  and  the  CIs  that  comprise 
each. 

Table  3 contains  the  Approved  Summary  Program  Breakdown  Structure  assumed 
for  the  CDS  acquisition  program.  The  corresponding  Preliminary  CVBS  is 
contained,  essentially,  in  Table  the  model  SOU's  table  of  contents,  because 
the  model  SCU  reflects  tne  Preliminary  CUBS  structure.  The  RFP  would  include 
both  the  Approved  Suaeary  PBS  and  the  Preliminary  CUBS  plus  their 
Dictionaries.  Exhibit  1 contains  the  cod el  SOW  task  statements. 
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Tabic  2 


SPECIFICATION  TIES:  CENTRAL  DISTRIBUTION  STSID* 

Central  Distribution  System  (CDS) 

External  Exchange  (EE)  Functional  Area 

special  Communications  Interface  Equipment  (SCIE)  Cl 
Communications  Computer  (CC)  Cl 
CC  Real  Time  Executive  (CCEX)  Cl 
CC  On-Line  Diagnostics  (CCOD)  Cl 
CC  Application  Program  fCCAP)  Cl 
CC  Facility  Software  (CCFS)  Cl 
(Off-Line  Executive) 

(Assembler) 

(Off-Line  Diagnostic  A Htintenacce  Software) 
(Utilities) 

Hub  Functional  Area 

Hub  Processor  (HP)  Cl 
Hub  Real-Tine  Executive  (HEX)  Cl 
Bub  On-Line  Diagnostics  (HOD)  Cl 
Hub  Application  Program  (HAP)  Cl 

(Message  Switching  A Processing) 

(Message  Logging  A Retrieval) 

(System  Status  and  Control) 

(Central  Tables) 

Hub  Facility  Software  (HFS)  Cl 
(Off-Line  Executive) 

(Compiler) 

(Assembler) 

(Off-Line  Diagnostic  a Maintenance  Software) 
(Utilities) 

Systea  Design  Aids  (SDA)  Cl 
(System  Design  Data  Base) 

(Systea  Design  Data  Base  Management  Prcgran) 

(Systea  Perfomance  Sinulation  Program) 

Systea  Test  Software  (STS)  Cl 
Systea  Exercise  Software  (SES)  Cl 
Internal  Exchange  (IE)  Functional  Area 

Internal  Exchange  Interface  Equipment  (IEIE)  Cl 
Internal  Exchange  Computer  (IEC)  Cl 
IE  Real-Time  Executive  (IEEX)  Cl 
IE  On-Line  Diagnostics  (IEOD)  Cl 
IE  Application  Program  (IEAP)  Cl 
J.E  Facility  Software  (IEFS)  Cl 
(Off-Line  Executive) 

(Asseabler) 

(Off-Line  Diagnostic  A Maintenance  Software) 
(Utilities) 


* Table  entries  contained  entirely  within  parentheses  are  not  CIs; 
instead  they  indicate  the  contents  of  CIs. 
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3.1  Mi lor  Assumptions 

The  sod el  SOW  paragraphs  reflect  the  following  major  asst  wpt  ions. 

a.  The  CDS  is  a oue-of-a-kind  Major  Defense  System.  Thus,  its 
acquisition  entails  no  Production  Phase.  However,  other  Major 
Defense  Systea  Acquisition  Life  Cycle  requireaents  apply. 

р.  The  hypothetical  planned  contract  covers  Full-Scale  Development 
Phase  work  only.  Prior  (i.s.,  Conceptual  Phase  and  Validation 
Phase)  effort  has  produced  a systea  design  represented  in  a coaplete 
Allocated  Baseline  and  a corresponding  Authenticated  Systea 
Specification  (teraed  the  CDS  System  Specification)  that  have  been 
validated  through  extensive  simulation  and  analysis.  Consequently, 
proposed  aodification  of  Development  Specifications  by  Offerors  is 
not  encouraged.  (See  LCEG,  Sections  4.3. 1 and  A. 3-2  for 
justification  of  these  assumptions) . 

с.  The  Allocated  Baseline  includes  a Computer  Program  Development 
Specification  for  the  Government-Furnished  (GFP)  System  Design  Aids 
CPCI  and  for  each  CPCI  that  requires  development,  plus  a Development 
Specification  for  each  equipment  Cl  to  be  developed.  The 
Authenticated  System  Specification  incorporates  a defined  equipment 
configuration,  including  specific  models,  types  and  nunbers,  for 
each  computer  to  be  acquired  for  the  system.  Development 
Specifications  are  presumed  unnecessary  for  commercially  acquired 
equipment  and  software.  However,  contractor  preparation  of  Product 
Specifications  for  such  commercially  acquired  equipment  and  software 
is  presumed.  The  RFP  incorporates  the  Authenticated  System 
Specification,  the  Allocated  Baseline,  and  a Computer  Program 
Product  Specification  for  the  GFP  CPCI. 

d.  Validation  Phase  work  has  developed  a complete  set  of  tie  prescribed 
planning  documents  identified  in  LCEG,  Section  A. A.  Each  Ofteror  s 
preparation  of  an  initial  version  of  the  SEMP  and  of  the  CPDP  as 
part  of  nxs  proposal,  and  the  subsequent  incorporation  of  the 
willing  Gfferor's  SEKP  and  CPD*  in  his  contract  after  Government 
approval,  is  also  presumed. 

e.  The  Full-Scale  Development  Phase  effort  is  not  segmented.  I.e.,  the 
SOW  defines  the  work  to  be  done  by  a single,  prime,  contractor  (who 
may  subcontract  some  of  the  work).  This  SOW  encompasses  all 
required  Full-Scale  Development  Phase  effort. 

Other  assumptions  are  mentioned  in  the  general  and  specific  comments  below. 

3.2  General  Comments  on  the  Model  SQM 

As  required,  the  SUW's  paragraph  structure  corresponds  to  the  Preliminary 
CtfBS,  except  for  the  SOW '3  introductory  paragraphs  (i.e.,  Exhibit  1 paragraphs 
1.  - A.).  Maintaining  this  correspondence  tends  to  increase  SOW  bulk,  because 
otherwise  a single  SOW  paragraph  could  often  prescribe  the  tasks  applicable  to 
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several  Preliminary  CUBS  Elements.  To  counter  this  adverse  tendency,  and  to 
minimise  introducing  inadvertent  inconsistencies,  the  model  SOU  typically 
prescribes  in  a higher-level  paragraph  work  applicable  to  a group  of  Element.* , 
and  omits  equivalent  language  from  the  lower-level  paragraphs  corresponding  to 
these  Elements. 

Conformance  to  UBS  definitions  sometimes  causes  closely  related  work  to 
be  prescribed  in  widely  separated  paragraphs.  For  example.  Preliminary  Design 
Beviews  (PDBs)  and  Critical  Design  Reviews  (CDXs)  are  prescribed  under 
paragraph  5-1-1,  Prime  Mission  Product,  while  the  closely  related  System 
Design  Reviews  (SDKs)  are  called  for  in  subparagraphs  of  paragraph  5- 1-5-1, 
Systems  Engineering  Management. 

In  other  cases  tasks  assigned  to  one  SOU  paragraph  (UBS  Element)  might 
alternately  be  assigned  to  another.  For  example,  system  test  planning, 
prescribed  under  Systems  Test  & Evaluation  (paragraph  5-l.t)  might  have  been 
prescribed  under  Systems  Shgineerir^  Management  (paragraph  5- 1-5-1)- 

Each  CUBS  Element's  Extended  PBC  (see  Section  A3)  is  incorporated  in  the 
corresponding  SOU  paragraph  as  part  of  the  SOU  paragraph's  title.  Each  SOU 
paragraph  is  also  assigned  an  indexed  pa rag rape  number  (e.g.,  5.1-1-*,  5-1-6) 
which  precisely  indicates  its  position  in  the  SOU';,  paragraph  tree.  Use  of 
this  numbering  system  in  addition  to  PBCs  for  paragraph  identification  is 
recommended  because  the  PBCs  comprise  an  obscure  and  somewhat  irregular 
numbering  system.  For  instance,  gaps  in  the  sequence  cf  prescribed  PBCs  could 
make  difficult  the  detection  of  omitted  SOU  paragraphs.  Also,  SOU  paragraphs 
(e.g.,  subparagraphs)  that  do  not  correspond  to  CUBS  Elements  may  not  be 
assigned  PBCs. 

A major  effort  has  been  nade  to  reference  rather  than  to  restate  in  SOU 
paragraphs  in formation  contained  in  ocicvent  paragraphs  of  Regulations, 
Specifications  and  Standards,  and  in  the  hypothetical  RFP's  specifications, 
CDRL  and  Delivery  Schedule.  Ibis  may  mcke  the  SOU  itself  somewhat  obscure. 
However,  in  practice  both  Government  and  contractor  users  of  the  SOM  would 
have  the  referenced  material  available,  and  should  read  each  SOU  paragraph 
concurrently  with  its  references,  as  reviewers  of  the  model  SOU  are  urged  to 
do.  The  chief  advantages  of  the  approach  selected  are  reduction  in 
inconsistency  and  greatly  reduced  SOU  bulk. 

3-3  specific  coweats 

Comments  on  specific  model  SOU  paragraphs,  preceded  by  ■MOTE:*1,  follow 
the  paragraphs  to  which  they  refer. 
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System  Test  Flaming 

5. 1.4.2 

1051 

3 

Development  Test  t Evaluation  (D7&E) 

5.1.4.2.1 

1051A 

4 

System  Functional  Testing 

5.1.4.2.2 

1051B 

4 

Systes  Performance  Testing 

5.1. 4.2. 3 

1051C 

t 

>el lability,  Maintainability  A 

5. 1-4. 2.4 

10510 

4 

Availability  Testing 
Security  Testing 

5.1. 4. 3 

1053 

7 

•» 

Operational  Test  A Evaluation  (OTAE) 

5-1. 4. 4 

1056 

3 

Test  A Evaluation  Support 

5.1.4. 5 

1057 

3 

Test  Facilities 

5-1.5 

1060 

2 

Systen  Program/Project  Management 

5.1. 5-1 

1061** 

3 

Systems  Engineering  Management 

5. 1.5- 1-1 

- 

4 

Systen  Failure  A iecovery  Analysis 

5.1. 5-1- 2 

- 

4 

Throughput,  A Response  Tine  Analysis 

5.1. 5- 1.3 

- 

4 

System  Design  Adjustment  A 

5*1. 5-1. 4 

4 

Maintenance 
Planning  for  Change 

5-1.5. 1-5 

- 

4 

Planning  for  System  Deployment 

5.1. 5-1. 6 

- 

4 

SEMP  Maintenance 

5-1. 5.1.7 

- 

4 

CPDP  Maintenance 

5- 1-5. 1.8 

- 

4 

System  Design  Reviews 

5-1. 5.1. 9 

- 

4 

Additional  ETfort 

5.1.5.1.10 

1061A 

4 

Reliability 

5.1.5.111 

10616 

4 

Maintainability 

5.1.5.1.12 

1061C 

4 

Parts  Control 

5.1.5.1.13 

1061D 

4 

Nomenclature 

5.1.5.1.14 

1061G 

4 

Electromagnetic  Compatibility 

5.1.5.1.15 

1061J 

4 

Security 

5-1.5.1.16 

10611 

4 

Survivability/Vulnerability 

5.1.5.1.17 

1061L 

4 

System  Safety 

5.1.5.1.18 

1061M 

4 

Communications  Long  Lines 

5.1.5.1.19 

1061P** 

4 

Value  Engineering 

5.1.5.1.20 

106  IQ 

4 

Availability 

5.1. 5. 2 

1062 

3 

Supporting  Project  Management  Activities 

5. 1.5.2. 1 

1062  A 

4 

Program  Management 

5. 1.5.2. 1.1 

1062AA 

5 

Prog ran/ Con tract  Work  Breakdown 

5. 1-5-2. 1-2 

1062AB 

5 

Structure 

Cost  Information  System 

5. 1.5.2. 1.3 

1062AC 

5 

Cost  Schedule  Systems 

5- 1.5.2- 1.4 

106 2 AD 

5 

Life  Cycle  Costs 

5. 1.5.2. 1-5 

1062AE 

5 

Schedule  Management 

5. 1.5.2  2 

1062B 

4 

Manufacturing  Management 

5. 1.5.2. 3 

1062C 

4 

Configuration  Management 

5. 1.5. 2. 4 

10620 

4 

Integration  of  Analyses  and 

Related  Computer  Support 
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Tibia  4 (Concluded) 


s» 

m • 

liiri 

giraru*  mi* 

5-1-5. 2. 5 

1062E 

4 

Quality/Xnspection 

5- t- 5-2.6 

1062G 

4 

S7I8FD 

5- 1-5-3 

1063 

3 

Integrated  Logistics  Support 

5- 1-5-3- l 

10634 

4 

Preoperatiooal  Supply  Support 

5-1- 5-3-2 

10638 

4 

Packaging 

5-1.5.33 

1063C 

4 

Transportation 

5-1- 5-3-4 

10630 

4 

Travel 

5-1-5.35 

1063C 

4 

Maintenance 

5. 1- 5-3-6 

1063C 

4 

Llaltod  Spares/Bepnir  Farts 

5-1- 5-* 

1064 

3 

Provisioning 
drew/Buaan  Factors 

5-1- 5-4.1 

1064A 

4 

Plain  Engineering 

5-1- 5.4.2 

1064C 

4 

Muipouer/  Personnel  Bequireaents 

5- 1.5.4. 3 

10640 

4 

Buaan  Factors  Test  4 Evaluation 

5-1.5 

1070 

2 

Data 

5-1. 6.1 

1071 

3 

Technical  Publications 

5.1. £-2 

1072 

3 

Engineering  Data 

5- 1.6. 2.1 

1072E 

4 

Engineering  4 Configuration 

5-1- 6.2.2 

10728 

4 

Doeunentatior. 

Buaan  Factors 

5-1- 6. 2. 3 

1072* 

4 

■elated  Design  bequireaents 

5- 1-6. 2. 4 

1072S 

4 

Systea/Subsystsa  Analysis 

5-1. 6. 2.5 

1072T 

4 

Test 

5-1- 6.3 

1073 

3 

ffanageaent  Eata 

5-1- 6- 3-1 

10734 

4 

Administrative  Management 

5-1- 6.3-2 

1C73F 

4 

Financial 

5-1- 6.3-3 

1073L 

4 

Logistic  Support 

5-1- 6. 3-4 

1073* 

4 

Procureaent/Prod action 

5-1-6. 4 

1074 

3 

Data  I^pository 

5-1-7 

1080 

2 

Operational /Site  Activation 

5- 1-7-1 

1061 

3 

Contractor  Technical  Support 

5.1-7- 2 

1083 

3 

Site  Conversion 

5.1.". 3 

1064 

3 

Systea  Asseably,  Installation  A 

5.1. 7. 3-1 

10644 

4 

Checkout  on  Site 
Operational  Site  Checkout 

5-1- 7-3-2 

1034B 

4 

CPDF  Checkout 

5-1- 7- 3-3 

1064C 

4 

CFMF  Checkout 

5-1- 7-4 

1065 

3 

AL?  Support  Facilities 

5.’. 7. 4.1 

10654 

4 

Q'DF 

5. 1.7- 4. 2 

1085B 

4 

CFKT 

* Prefix  this  code  with  the  letter  (i.e.t  1,  B,  C...}  ass igned  to  the 

ccn tract-  E.g. , A1362C  is  the  PBC  for  the  Configuration  ftanageaent  task 
under  the  Acquis it loo  pragma's  first  contract. 

••  See  Table  t,  final  two  'entries. 
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Exhibit  1 


MODEL  FULL-SCALE  DEVELOPMENT  PHASE  SOU  PtlASRAPHS 


1.  OBJECTIVES 

Uw  overall  objective  of  this  contract  is  to  develop  and  install  at  the 
■atissal  Command  Center,  as  prescribed  in  the  contract's  Delivery  Schedule,  an 
operable,  common,  collection  and  dissemination  center  for  digital  messages, 
termed  the  Central  Distribution  System  (CDS).  The  CDS  will  provide  the 
Rational  Command  with  capability  for  handling  a greater  diversity  and  volume 
zT  traffic  than  it  can  today,  with  substantially  increased  throughput  and 
reduced  delivery  tines. 


2.  SCOPE 

This  Statement  of  tfork  (SOU)  covers  tne  detailed  design,  development, 
assembly,  integration,  docwestation,  installation,  and  test  of  a single  CDS. 
The  SCN  also  covers  .on tractor  assistance  in  training,  evaluation,  and  pilot 
operation  of  the  CDS.  The  CDS  shall  comprise  both  equipment  and  software, 
including  some  commercial  items  and  some  Government-Furnished  Property  (GFP) , 
able  to  meet  the  requirements  of  the  CDS  System  -Specification  and  the  other, 
related,  specifications  identified  therein. 


3.  SOU  SELATIORSHIP  TO  THE  CUBS 

The  Contract  Ucrk  Breakdown  Structure  (CUBS),  also  included  in  this 
contract,  graphically  portrays  the  work  to  be  accoaplished , consistent  with 
the  contract’s  scope  (SOU  paragraph  2).  The  CUBS  also  incorporates  a 
Dictionary,  which  defines  the  scope  of  each  CUBS  Element.  The  CUBS  and  this 
SOU's  task  descriptions  (contained  in  SOU  paragraph  5)  are  assigned  Extended 
Program  Breakdown  Codes  (PECs)  per  AFSCH  173-*,  Program  Breakdown  Structure 
and  Codas  and  ESDP  600-4,  Statement  of  Uork  Preparation  ftilde.  including 
Change  1.  (Each  task  description's  paragraph  heading  includes  the  task's  PBC 
if  the  paragraph  corresponds  to  a CUBS  Element).  Cost  accounting  coding  and 
Configuration  Identification  shall  oe  kept  consistent  with  this  coding  scheme. 


4.  RELATED  DOCUMEHTS 

The  Specifications,  Contract  Data  Requirements  List  (CDRL),  Delivery 
Schedule,  ailitary  specifications  and  standards.  Data  Item  Descriptions 
(DIDsli,  Govenutent-approved  portions  of  the  contractor's  proposal,  and  other 
documents,  to  the  extent  that  they  are  referenced  in  this  SC*i  subsequently,  or 
in  ref  ere-,  ed  portions  of  documents  referenced  there  in^urther  define  the 
work  required  under  this  contract.  In  particular,  thf  Delivery  Schedule  and 
CDRL  define  the  requisite  Periods  of  Performance  and  delivery  dates  applicable 
to  all  SOW-defined  tasks  and  their  products.  These  related  documents  are 
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either  included  in  this  lequest  for  Proposal  (IF?)  or  nay  be  obtained  froai  the 
Procuring  Contracting  Officer  (PCO). 


5.  COimCTOR  TASKS 

The  contractor  shall  perfora  the  following  tasks,  and  shall  segregate  the 
costs  of  all  such  effort  by  the  lowest-level  CUBS  Element  to  which  the  effort 
applies. 

*5.i  PBC  41000.  Central  Distribution  System 

Design  4 develop  (or  otherwise  acquire),  and  integrate,  install,  4 test, 
the  equipaent  and  software  necessary  to  aeet  the  requirements  of  the  CDS 
Si rstca  Specification,  plus  those  of  the  several  related  Configuration  I tea 
(Cl)  Developaent  Specifications  and  other  specifications,  attached  to  or 
referenced  in  the  contract.  Perfora  related  services  including  training. 
System  Test  planning,  Systeas  Engineering,  and  saintenance  of  the  CDS 
equipaent  and  software  developed  or  otherwise  acquired.  Sup pert  Government 
Prog ran  Management  and  Site  Activation  effort.  Provide  and  operate  needed 
support  equipaent  peculiar  to  the  CDS.  Generate  and  provide  related 
docuaentation  and  other  relevant  Data  as  specified  in  the  Contract  Data 
Requirements  List  (CDRL)  incorporated  in  the  contract.  Perfora  these  tasks 
consistent  with  the  CDS  Svstea  Specification.  the  Systea  Engineering 
NSnageaent  Plan  (5EMP),  the  Coaputer  Prograa  Developaent  Plan  (CPDP) , the  Test 
4 Evaluation  Mister  Plan  (TEMP),  the  Training  Plan,  and  the  Delivery  Schedule, 
all  incorporated  in  the  contract.  This  paragraph  encoapasses  subsequent 
paragraphs  5-1-1  - 5- 1-7.4,  and  their  subparagraphs. 

•5-1-1  ffec  AiQiQ- trim  maaias  fcaiagt 

Design  4 develop  (or  otherwise  acquire),  and  install  4 test,  each 
of  the  equipoent  CIs  and  Coaputer  Prograa  Configuration  Iteas  ( CPCIs ) 
identified  in  the  CDS  Svstea  Specification  to  aeet  this  specification's 
requirements , and  those  of  the  other  specifications  referenced  therein. 
Integrate  these  CIs  into  Functional  Areas  (FAs),  and  the  FAs  into  a CDS  able 
to  aeet  all  CDS  Svstea  Specification-prescribed  requirements. 

•5.1.1a  Generation  of  Specifications.  Generate  a draft  and  a final 
Product  Specification  for  each  equipaent  Cl,  and  a Coaputer  Prograu  Product 
Specification  for  each  CPCI  developed,  and  for  each  CPCI  acquired  froe  a 
coaaercial  source,  except  as  otherwise  provided  in  subsequent  paragraphs. 
Document  the  intra-CI  interfaces  in  the  CPCIs'  Coaputer  Prograa  Product 
Specifications  and  the  equipaent  CIs'  Product  Specifications.  Also  include 
among  each  Product  Specification's  Quality  Assurance  provisions  a Verification 
Matrix  that  shows  by  paragraph  reference  how  each  of  the  Product 
Specification's  design  requirements  is  to  be  satisfied.  Dccuaent  the 
interfaces  among  CIs,  tne  interfaces  among  FAs,  and  the  CDS'  external 
interfaces  in  Engineering  Drawings,  as  prescribed  in  mL-STD-483(USAF) . 

Update  each  of  these  docuncnts  after  its,  delivery  tc  reflect  changes  to  the 
corresponding  CIs;  e.g.,  as  a result  of  integration  and  testing. 
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•5.1. 1b  Cl  Design  jgjfle  aad  Test*.  Plan  and  conduct  a Preliminary 
Design  Review  (PDR) , a Critical  Design  Review  (CD*) , and  Prelininary 
Qualification  Tests  (PQTs)  for  each  Cl  developed,  and  Formal  Qualification 
Tests  (FQTs) , a Functional  Configuration  Audit  (FCA),  a Formal  Qualification 
Review  (FQB) , and  a Physical  Configuration  Audit  (PCI)  for  each  Cl  developed 
or  commercially  acquired,  as  specified  in  HIL-STD-A83(OSAF) , 

Wm— ament  Practices  SalBL  ffiUlPTht.  Tl 

Appendix  111,  in  WL-STD-152K0SAF) , Technical  Reviews  and  Audita  for  Svs» 
t.  end  Computer  Programs,  and  in  the  contract's  Delivery  Schedule. 


The  PQT's  need  only  assure  the  correct  operation  of  each  Cl's  parts  and 
collect  data  unobtainable  later,  as  specified  in  HIL~STD-A83(USAF) . Prepare 
and  deliver  a draft  and  a final  Test  Plan,  plus  draft  and  final  Test 
Procedures,  for  each  Cl  developed  or  acquired  commercially.  Conduct  tests  for 
each  Cl  per  the  TEMP  and  the  Cl's  Soverment-approved  Test  Plan  A Test 
Procedures.  Document  the  results  of  the  Cl  tests  in  Test  Reports.  Notify  the 
Government , on  request,  of  the  results  of  informal  contractor- run  tests,  and 
identify  all  informal  test  reports  in  the  monthly  Data  Accession  List/Internal 
Data  (see  paragraph  5.1.6c). 


MOTE:  KIL-STD-152KUSAF)  should  be  reviewed  and  its  requirements  carefully 

tailored  to  the  needs  of  each  systes's  design  and  acquisition  approach.  Such 
tailoring  has  not  been  attempted  here  because  it  would  entail  elaborate 
explanation  of  system  assumptions.  Also,  see  ESD-TR-75-85 , An  Air  Force  Guide 
for  Monitoring  and  Reporting  Software  Envelopment  Status . for  further 
discussion  of  design  reviews  and  tests,  including  considerations  that 
tailoring  should  reflect. 


1QX£:  three  related  System  Design  Reviews  (SDRs)  are  prescribed  in  paragraph 

5. 1.5. 1.8.  This  and  other  separation  of  closely  related  tasks  result  from  SOU 
paragraph  conformance  to  prescribed  WBS  Element  definitions. 

•5.1.1c  Guidance.  Perform  this  task  in  consonance  with  the  SEHP,  CPDP, 
TEMP,  a Government-approved  System  Test  Plan,  Government-approved  System  Test 
Procedures,  the  Training  Plan  and  the  Delivery  Schedule.  This  task 
encompasses  the  work  prescribed  in  paragraphs  5-1- 1-1  - 5- '«.!.*.*  and  their 
subparagraphs.  This  task  excludes  the  effort  encoapassed  by  paragraphs  5-1.2 
- 5. 1.7. A and  their  subparagraphs . 


5. 1.1.1  PBC  All  10.  Communications. 

5.1. 1- 1-1  P8C  A3111/111.  special  Comaunlcatlo ns  interface  Equipment 
(SCIE)  Cl.  Design,  develop,  fabricate,  assemble,  and  test  the  SC IE  Cl  to  meet 
its  allocated  CDS  System  Specification  requirements  and  the  requirements  of 
its  Developoen*  Specification. 

5. 1.1. 1- 2  PBC  1311 1/131 . Internal  Exchange  Interface  Equipment  (IEIE) 
gj.  Design,  develop,  fabricate,  assemble  ana  test  the  IEIE  Cl  to  meet  its 
allocated  CDS  System  Specification  requirements  and  those  of  its  Development 
Specification. 

•5. 1.1.2  PBC  A* 1 10.  Automatic  DaU  Processing  Equipment.  Purchase  from 
their  manufacturers  the  eqi ipeent  comprising  each  of  the  Communications 
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Computer  (CC)  Cl,  the  Bub  Processor  Cl,  and  the  Internal  Exchange  Computer  Cl, 
and  their  design*  and  user-oriented  documentation,  as  defined  in  the  CDS 
Sts ten  Specification.  Assemble  and  integrate  each  such  Cl,  and  test  it 
against  its  requirements,  as  defined  in  the  CDS  Srstem  Sn-ciflcation  and  in 
its  SoTerament-approTed  Test  Plan/Procedures.  Report  any  failures  to  satisfy 
these  requirements,  or  inadequate  documentation.  Propose  plans  to  correct 
such  deficiencies  or  to  avoid  them  during  CDS  application.  Modify  and 
implement  these  plans  as  directed  by  the  Government.  Arrange  maintenance  for 
each  equipment  Cl  by  its  supplier  during  the  contract  period.  Base  each  Cl's 
Product  Specification,  to  the  maximum  feasible  extent,  on  its  supplier's 
specifications  and  engineering  drawings,  augmented  by  the  corrections  and 
vsrfcarounds  planned  or  implemented  to  correct  any  deficiencies  detected. 

MOTE:  Under  the  assumed  acquisition  concept,  the  Government  is  responsible 

for  any  failure  of  the  equipment  configuration  to  meet  mission  requirements, 
provided  the  equipment 's  performance  satisfies  Government-approved  tests. 
However,  Validation  Phase  system  design  verification  is  presumed  to  have 
minimized  the  risk  of  such  failure  (see  LCEG  Sections  4.3.1  and  4-3- 2>.  Thus, 
the  testing  prescribed  is  paragraph  5- 1.1.2  is  intended  to  assure  the 
purchased  equipment's  satisfactory  performance. 

•5.1. 1.2.1  P5C  A41 12/112.  Communications  Computer  (CC)  Cl.  See 
paragraph  5. 1.1.2. 

•5-1-1. 2. 2 PBC  Ah  Hi/ 121.  Hub  Processor  Cl.  See  paragraph  5. 1. 1.2. 

•5-1. 1*2.3  PBC  A4112/112.  Internal  Excha»yt  fTfi}  router  Cl.  See 
paragraph  5. 1.1.2. 

•5. 1.1*3  PBC  AA210.  Computer  Programs.  Develop  or  acquire,  test, 
document,  and  maintain  throughout  the  contract  period,  each  of  the  CPCIs 
identified  below.  Compile  a Computer  Prograrzing  Manual  and  a Users'  Manual 
(Computer  Program)  for  each,  and  update  thee.  to  reflect  any  changes  made  to 
the  CPCIs  during  the  contract.  Include  i-  each  Computer  Program  Product 
Specification  a matrix  that  shows  which  _>f  the  CPCI's  Computer  Prog  ran 
Components  (CPCs)  implement  each  of  the  Functions  defined  in  its  Computer 
Program  Development  Specification  (r:  other  definitive  sources,  if  the  CPC I 
has  no  Computer  Program  Development  Specification) . 

•5- 1.1. 3a  Software  to  be  !*cvclopcd.  Design,  develop,  document,  test, 
update,  and  maintain  each  of  the  following  CPCIs,  to  satisfy  tbe  Computer 
Program  Development  Plan  (CPDP),  the  CPCI's  allocated  CDS  System  Specification 
requirements,  and  the  requirements  of  its  Computer  Program  Development 
Specification.  Deliver  incremental  CPCI  Versions  and  their  documentation 
(e.g..  Version  Description  Documents)  as  specified  m the  CPDP.  Specify  in 
these  CPCI's  Test  Plans  and  Test  Procedures  the  tests  to  be  performed  on  each 
Version. 


SSL 
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*4212/ 11 3 CC  Peal-Time  Executive  Cl 
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1*215/11* 

CC  Os-Line  Diagnostics  Cl 

11211/115 

CC  Application  Program  Cl 

1*212/122 

Hub  Meal-Time  Executive  Cl 

1*215/123 

!Jub  On-Line  Diagnostics  Cl 

11211/121 

Hub  Application  Program  Cl 

A121F/127 

System  Test  Software  Cl 

1*21 J/ 128 

System  Exercise  Software  Cl 

11211/135 

IE  Application  Program  Cl 

MOTE:  The  System  Test  Software  Cl  and  the  System  Exercise  Software  Cl  are 

presumed  defined  to  operate  on  all  Hub  Processor  configurations  appropriate  to 
CDS  system  test  and  exercise,  respectively.  Also  see  note  on  paragraph 
5- 1.4. 1 - 


•5-1. 1-3.1  PBC  H2 <2/113.  CC  Real-Time  Executive  Cl.  See  paragraph 

5.1.1.3a- 

•5.1. 1-3-2  PBC  11215/ 111.  CC  On-Line  Diagnostics  Cl.  See  paragraph 
5.1.1.3a. 

•5-1. 1-3*3  PBC  H211/115.  CC  Application  Program  Cl.  See  paragraph 
5.1.1.3a. 

•5. 1-1.3-*  PBC  4*212/116.  CC  Facility  Software  Cl.  Acquire  from  the 
MTTIMIMI  Corporation  the  components  of  the  CC  Facility  Software  Cl,  comprising 
the  CC  Off-Line  Executive,  the  CC  Assembler,  the  CC  Off-Line  Diagnostic  A 
Maintenance  Software,  and  the  CC  Utilities.  Also  acquire  their  design-  and 
user-oriented  documentation . 


MOTE:  This  paragraph  assumes  the  Government's  right  to  use  this  software  and 

its  documentation  throughout  the  CDS'  lifetise  as  a result  either  of  standard 
software  supplier  contract  terms  or  a special  agreement.  Obtaining  adequate 
Government  rights  to  use  design  documentation  (e.g..  Operating  System  coding 
and  loeic  manuals)  has  been  a problem  in  some  past  acquisitions.  Hence,  the 
appropriate  agreements  should  be  assured  {e.g.,  by  negotiation)  before 
equipment  selection,  and  certainly  before  directing  a development  contractor 
to  use  the  selected  software. 


•5.1.1-3-**  Testing  and  Maintenance . Test  each  of  these  programs  to 
assure  its  compliance  with  its  CDS  System  Soec if icat ion-defined  requirements. 
Report  any  failures  to  meet  these  requirenersts,  and  propose  plans  for 
correcting  their  causes  or  avoiding  the*  in  the  CDS  application.  Modify  and 
implement  such  plans  as  directed  by  the  Government.  Maintain  this  software 
during  the  contract  period. 
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MOTE:  This  software  is  presumed  to  have  been  tested  during  the  Validation 

Phase  as  a basis  for  its  selection  and  for  allocating  its  ays tea  requireaents 
(see  LCBG,  Section  A.3.1).  Thus,  the  testing  prescribed  in  the  aodel  SOU 
paragraph  is  mminly  intended  to  detect  ary  defective  copies  or  wrong  Versions. 

*5.1.i-3-*b  CPCI  Product  Specification  Generation.  Base  each  Cl's 
Goaputer  Prograa  Product  Specification,  to  the  maxim's  extent  possible,  on 
equivalert  MTTIMIII  Corporation  docuaentation , with  appropriate  adjustment  for 
corrections  and  workarounds  devised  as  a result  of  tenting. 

KITE:  The  CDUL  entry  calling  for  preparation  of  these  CPCI  Product 

Specifications  should  (directly  or  by  DID  reference)  allow  deviation  fro** 
strict  (i.e.,  MIL-S-83490,  Specifications.  Types,  and  Forms,  Fora  1)  forest 
requireaents,  ss  long  as  all  essential  information  and  useful  format  Is 
prescribed.  Use  of  the  looser  MIL-S-83*90  Form  2 or  Fora  3 standards  should 
be  considered  to  restrain  costs. 


*5.1. 1-3-5  PBC  1*212/122.  Hub  ical-Tiac  Executive  Cl . See  paragraph 
5-1- 1-3*. 

•5.1. 1-3.6  PBC  1*215/123-  Bub  On-Line  Diatnostics  Cl.  See  paragraph 
5.1.1.3a. 


•5-1. 1-3-7  PBC  *<211/124-  Bub  Application  prograa  Cl-  See  paragraph 
5-1-1. 3a- 


•5.1. 1-3-8  PBC  44217/125.  Hub  Facility  Software  Cl.  Acquire  from 
Hega there  Information  Systems,  Inc.  (MIS),  each  of  the  following  software 
packages,  and  their  user-  and  design-oriented  docuaentation:  Off-Line 

Executive,  JOVIAL  (J3>  Compiler,  Assembler,  Off-Line  Diagnostic  A Maintenance 
Software,  and  Utilities.  These  comprise  the  Bub  Facility  Software  Cl. 


•5.1.1.3.8a  Testing  and  Maintenance-  Test  each  such  Kib  Facility 
Software  Cl  computer  program  to  assure  its  compliance  with  CPS  System 
Specification  requireaents.  Report  any  failures  to  weet  these  requirements 
and  propose  plans  to  correct  their  causes  or  to  avoid  them  in  the  CDS 
application.  Modify  and  implement  such  plans  as  directed  by  the  Government. 
Maintain  this  software  during  the  contract  period. 


•5- 1.3.6b  CPCI  Product  Specification  Generation.  Base  the  Hub 
Facility  Software  Cl's  Computer  Program  Product  Specification  00  MIS 
docuaentation  to  the  maximum  feasible  extent. 


MOTE:  See  notes  on  paragraph  5-1.1. 3. A.  and  its  subparagraphs. 

•5.1. 1.3.9  PBC  AA21E/126-  System  Design  Aids  Cl.  Accept  from  the 
Government  as  Government-Furnished  Property  (GFP)  the  System  Design  Aids  Cl 
and  its  docuaentation,  for  use  as  prescribed  in  other  paragraphs  of  this  SOW. 

aOTE:  The  GFP  System  Design  Aids  Cl  is  presumed  to  include  a discrete-event 

simulator,  i.e.,  the  System  Performance  Simulation  Program,  a System  Design 
Data  Base,  and  a System  Design  Data  Base  Management  Program,  all  developed 
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before  and  during  the  Validation  Phase  mainly  to  help  formulate  and  validate 
system  design  alternatives  (see  LCEG,  Table  1,  Sets  J A 0;  Table  2,  Set  E;  and 
Sections  3-3,  *.3.1,  and  4.3.2).  The  model  SOW  directs  the  Full-Scale 
Development  Phase  contractor  to  accept,  use,  and  extend  these  tools  to  promote 
continuity  and  efficiency  in  system  design  evolution  and  assessment.  Specific 
uses  of  the  System  Design  Aids  Cl  are  mentioned  is  paragraphs  5. 1-5-1  -2  and 
5. 1.5.1 -3-  This,  or  any  other,  GFP  software  imposed  on  a contractor  should  be 
thoroughly  tested  and  well  documented  to  avoid  contractor  claims  that  its 
deficiencies  inpair  contractor  performance. 

•5.1-1-3-10  PSC  A421F/127.  Srf.tem  Test  Software  Cl.  See  paragraph 
5.1.1.3a. 

•5-1.1-3-11  ?PC  A421J7 126.  System  Exercise  Software  Cl.  Sec  paragraph 
5.1.1.3a. 


•5.i-i.3b  /£  Equivalents  of  CC  Software.  The  following  IE  CPCIs  should 
be  identical  to  the  corresponding  CC  CPCIs: 


ie  fsc 

A4212/133 
14215/ 134 
A421Z/136 


IE  Cl  Mane 

IE  Real-Time  Executive 
IE  On-Line  Diagnostics 
IE  Facility  Software 


££-fgC 
A4212/1 13 
A4215/H4 
A421Z/116 


CC  Cl  dame 

CC  Real-Time  Executive 
CC  On-Line  Diagnostics 
CC  Facility  Software 


Hake  a copy  of  each  of  the  CC  CPCIs,  assign  it  the  corresponding  IF  CFCI 
identification,  and  test  it  to  assure  its  correct  operation.  Report  any 
failures  to  meet  these  requirements  and  prepare  plans  to  correct  their  causes 
or  to  avoid  them  in  the  CDS  application.  Hodify  and  implement  such  plans  as 
directed  by  the  Government.  Maintain  this  software  during  the  contract 
period.  Prepare  its  Product  Specification  as  an  Addendum  Specification  based 
on  its  CC  CPCI  counterpart. 


MOTE:  See  notes  under  paragraph  5-1- 1.3*4  and  its  subparagraphs . Similar 
deviation  from  HIL-S-8349G  For*  1 should  be  allowed. 


•5.1.1.3.12  PSC  A4212/133.  IE  Real-Time  Executive  Cl. 
5.1.1.3b. 


See  paragraph 


•5.1.1.3.13 

5.1.1.3b. 

•5.1.1-3-14 

5- 1. 1.3a. 

•5.1.1.3.15 

5.1.1.3b. 


PSC  i*2 15/.U*  • IE  (3.  See  paragraph 

PSC  4421.1/115. IE  Application  Program  Cl.  See  paragraph 

PSC  4*1  U/ 1,3$. IE  Facility  Software  Cl.  See  paragraph 
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10TE:  Specif  CBRL  entries  Bust  be  provided  to  call  for  delivery  of  the 

computer  storage  media  containing  all  CPCI  Versions  to  be  provided  by  the 
contractor  (see  guideoook  Section  C 2.1.2). 

110.  Integration  * Assembly.  Integrate  the  three  Fis 
defined  in  the  CBS  S vs  tea  Specification  into  a functioning  whole  able  to 
satisfy  all  CPC  System  Specification-defined  requirements . Correct  any 
incompatibilities  aaong  the  Fis. 

*5.1.1.*.1  PBC  A111*.  System  External  Interfaces.  Correct  any 
incompatibilities  between  the  CDS  and  the  external  systems  with  which  it 
interfaces-  Identify  all  CBS  Systems  Specification  changes  thereby  entailed. 

•5. 1.1. *-2  PBC  11111/11.  ££  Functional  Area  Integration.  Correct  any 

incompatibilities  aaong  the  Interfacing  EE  CIs:  the  SCIE,  CC,  CC  Real-Time 

Executive,  CC  On-Line  Diagnostics,  CC  Application  Program  and  CC  Facility 
Software.  Identify  all  changes  in  specifications  and  Engineering  Drawings 
thereby  entailed. 

•5. 1-1. *. 3 PBC  All  IP/12.  Hub  Functional  Area  Integration.  Correct  any 
incompatibilities  aaong  the  interfacing  Hub  CIs:  the  Hub  Processor,  Hub  Real- 

Time  Executive,  Hub  On-Line  Diagnostics,  Hub  Application  Program,  Hub  Facility 
Software,  System  Design  Aids,  System  Test  Software,  and  System  Exercise 
Software.  Identify  all  changes  in  specifications  and  Engineering  Drawings 
thereby  entailed. 


•5- 1.1. *. A PBC  All  1 VI 3.  IE  Functional  Area  Integration,  Correct  any 
incompatibilities  aaong  the  interfacing  IE  CIs:  the  IEIE,  IE  Computer,  IE 

Real-Time  Executive,  IE  On-Line  Diagnostics,  IE  Application  Program,  and  IE 
Facility  Software.  Identify  all  changes  in  specifications  and  Engineering 
Drawings  thereby  entailed. 

5-1.2  PBC  A 1020.  Training 

The  Air  Training  Command  (ATC)  will  procure  Type  1 (i.e., 
contractor)  special  training  courses  on  CDS  Operation,  Equipment  Maintenance, 
System  Analysis  i Siaulation,  Systea  Exercise,  and  Software  Maintenance  A 
Modification,  for  an  initial  cadre  of  Using  Co  stand  personnel  and  A7C 
instructors.  These  Government  personnel  will  already  be  qualified  in  their 
respective  Air  Force  specialties.  Plan  for  such  training,  which  will  be 
conducted  under  separate  contract  with  ATC.  Develop  a syllabus  for  each 
course,  and  schedule  the  courses  consistent  with  availability  of  personnel  ano 
required  equipment.  Assuse  that  the  courses  will  be  independent  of  one 
another  and  that  eacn  will  be  attended  by  at  least  two  ATC  instructors  plus 
the  numbers  of  Using  Command  personnel  of  each  skill  category  estimated 
necessary  to  operate,  exercise,  maintain,  and  modify  the  CDS  as  a result  of 
the  Crew/Humar.  Factors  task  (paragraph  5. 1.5.4).  Generate  a Technical  Report 
containing  all  assumptions,  plans,  syllabi,  course  schedules,  and  other 
pertinent  information  about  this  training. 

5. 1.2.1  PBC  A 1021.  Ecuioaent.  Plan  the  availability  of  all  equipment 
and  other  materials  necessary  for  each  course  session,  including  the  equipment 
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maintenance  ani  spare  parts  for  the  equipment  to  be  used  in  training. 

Minimize  the  equipment  to  be  purchased  or  developed  expressly  to  conduct  Type 
1 training. 

5- 1.2.2  PBC  1102? . Facilities.  Plan  use  of  adequate  classroom, 
computer,  core  uni cat ions  and  display  facilities  at  the  contractor's  plant  and 
at  the  National  Command  r enter  for  the  courses  identified  ix.  paragraph  5.1.2. 

5. ’-2. 3 PBC  11029.  Services.  Identify  instructors  for  the  courses 
identified  in  paragraph  5-1-2,  and  specify  their  qualifications.  Identify  any 
other  services  required. 

5-1-3  ££CJLm*sL Peculiar  port  i&gjgment  and  Maintenance 

5- 1-3-1  1? in tenancy  Ccnceot- 

5- 1-3-2  Built-In  Test  Equipment  (BITE). 

5- 1-3-3  PBC  AlfljLb-  Organizational /In  termed  late- 

5-1-3-H  ?S.C  .k\m,  Pc^gt- 

•5.1.*  PBC  MQ5Q-  Systems  Test  * Evaluation 

Conduct  and  support  a System  Test  and  Evaluation  prograx  per  the 
CDS  Svstea  Specification:  the  TEMP;  and  as  described  in  the  following 
subparagraphs.  CDS  Systen  Test  and  Evaluation  shall  include: 

a.  the  effort  and  otter  costs  of  adaptiiy  and  usi.^  computer  programs 
to  obtain  and  validate  engineering  data  on  the  behavior  of  the  CDS; 

b.  the  1 tailed  planning,  conduct  a rso  support  of  system  tests; 

c.  [ reparation  of  a Government-approved  System  Test  Plan  and 
Governaent-approved  System  Test  Procedures; 

d.  the  reduction  of  Systen  Test  data; 

e.  the  preparation  and  distribution  of  Systea  Test  Reports: 

f.  the  "csts  of  all  equipment  and  material  consumed  during  System 
Tests;  and 

g.  the  effort  and  other  costs  entailed  tc  design  & produce,  or 
purchase,  and  tc  maintain  models,  fixtures  and  instrumentation 
explicitly  to  support  Systen  Testing. 

fils  task  excludes  the  test-related  activites  defined  in  paragraphs  5-1.1, 
3.1.2,  5.1-3,  5-1-5,  5-1  6 and  5-1-7  and  their  subparagraphs 


40 


MOTE:  General  planning  for  system-level  DTAE  may  also  be  considered  a Systems 

Engineering  Task  (see  paragraph  5. 1-5-1)  per  MIL-STi>-499A(USAF) , Eheinccrlm 

Utmost*  ♦ 

*5- 1-0-1  Svs tee  Test  Planning.  Develop  and  Maintain  a System  Test  Plan, 
subject  to  Government  approval  of  the  original  and  all  changes  (e.g.,  to 
reflect  CDS  System  Specification  changes  and  TEMP  changes).  Incorporate 
appropriate  provisions  governing  Government/con tractor  relations,  eutual 
responsibilities,  and  notification  about  schedule  changes,  deviations,  and 
other  problems.  Develop  concrete  System  Test  Procedures,  to  implement  the 
Systes  Test  Plan,  and  to  meet  the  Quality  Assurance  provisions  of  the  CDS 
System  Specification.  »lan  the  specific  system-level  tests,  per  MIL-STD- 
*99A(USAF),  Management,  paragraph  10.1-3,  with  the  help  of  the 

Flow  Path  Identifier  in  the  Systes  Test  Software  Cl  (see  SOW  paragraph 
5-1-1.3-10).  Also,  incorporate  unsatisfied  Cl  test  requirements  from  the 
equipment  Cl  Product  Specifications ' and  Cocputer  Program  Product 
Specifications'  statements  cf  system-level  testing  requirements , from  the  CIs' 
Final  Test  Reports,  fro®  the  CIs'  FCA,  PC A,  and  FQR  minutes , and  from  any 
other  reports  that  indicate  the  need  for  specific  testing  or  retesting.  Plan 
the  system-level  tests  and  Systes  Test  Procedures  to  make  maximum  effective 
use  of  the  Systes  Test  Software's  workload  generation,  automated  test 
sequencirg,  and  data  reduction  capabilities.  Schedule  the  System  Tests, 
subject  to  Government  approval.  Refer  to  the  Systes  Test  Software's  Computer 
Pregras  Development  Specification  for  definition  of  this  CPCI's  capabilities. 

KOTt.:  Use  of  extensive  Systes  Test  Software  tc  automate  in  part  the  System 

Testing  process  is  assumed.  Such  test  aids  should  include  routines  to 
identify  transaction  flow  paths,  to  generate  test  workloads,  to  time  critical 
functions-  to  trace  a^d  ccunt  executions  of  flow  paths,  to  store  expected 
results  and  compare  then  witn  actual  results,  to  control  automatically  test 
presentation , test  result  collection  ar.d  test  sequencing  (including  actions 
normally  initiated  by  operators),  and  to  reduce  test  results.  An 
appropriately  designed  package  could  speed  up  testing  by  orders  of  magnitude 
compared  to  typical  ad  noc  testing  nethods,  allowing  tests  to  be  performed 
more  quickly  and  cheaply.  Tneir  use  would  also  reduce  considerably  the  number 
of  occasions  on  which  a "cast  of  thousands*  must  be  present  for  System  Tests. 
Deve! -scent  cf  tne  Systes  Test  Software  by  the  Full-Scale  Development  Phase 
contractor  i*  assuaed.  This  software  is  further  assumed  to  cooprise  a CPCI 
subject  to  the  same  Government  control,  testing,  and  documentation  as  other 
CPCIs,  tc  assure  its  satisfactory  quality  (which  is  normally  well  worth  the 
cost  of  such  formality) . Alternately,  the  Systes  Test  Software  sight  be 
prepared  during  the  Validation  Phase  and  its  use  imposed  as  GFr  or,  the  Full- 
Scale  Developcer.t  Phase  contractor,  khere  feasible,  this  alternative  is 
attractive,  because  it  would  eliminate  or  reduce  possible  problems  of  the 
Systes  Test  Software's  late  delivery,  novelty,  and  low  initial  reliability.  A 
tnird  alternative  would  impose  on  the  Full-Scale  Development  contractor  one  or 
more  standard  GFP  test  aids.  Mixtures  of  these  alternatives  should  also  be 
considered.  Any  test  software  imposed  as  GFP  should  be  thoroughly  tested  and 
well  documented  before  delivery  to  a contractor. 

2 P5C  A 1 35 1 . Development  Test  & Evaluation  (DTAE).  Conduct  and 
support  systea-level  DTAE  of  the  CDS,  as  defined  in  the  TEMP.  This  task 
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includes  the  detailed  planning,  conduct,  and  support  of  tests  to  verify  that 
CDS  engineering  design  and  development  are  complete;  that  the  functional, 
performance,  design  and  interface  requirements  of  the  CDS  System  Specification 
have  been  achieved;  and  that  the  CDS  engineering  design  is  practical, 
reliable,  maintainable,  secure,  and  safe  far  operational  use.  System-level 
DUE  shall  emphasize  the  CDS'®  ability  to  satisfy  the  following  objectives: 

a.  perform  each  of  its  Functions  within  the  required  response  time, 
under  each  specified  workload,  while  meeting  the  Function's  accuracy 
requirements ; 

b.  meet  its  human  factors  requirements; 

c.  meet  its  security  requirements; 

d.  operate  correctly  with  the  data  processing  and  communication  systems 
defined  as  its  external  interfaces;  and 

e.  suffer  faults,  and  consequently  undergo  reconfiguration  and  correct 
recovery  of  its  data  and  control,  as  necessary  to  meet  its 
Probability  of  Success  requirements. 

System-level  DT4E  shall  also  verify  that  the  CDS'  user-oriented  documentation 
(e.g.,  its  Positional  Handbooks)  are  correct  and  otherwise  effective  tools  for 
their  intended  users.  This  task  excludes  testing  of  the  CIs  and  FAs  acquired 
or  developed,  and  integrated,  under  tasks  prescribed  in  paragraph  5.1.1  and 
its  subparagraphs , except  to  ascertain  their  behavior  as  part  of  the  overall 
CDS,  and  except  to  conduct  Cl  and  FA  testing  infeasible  under  those  tasks. 

•5.1. A. 2.1  PBC  A1Q51A.  System  Functional  Test lag.  Conduct  tests  of 
each  Function  defined  in  the  CDS  System  Specification  to  verify  that  all  CDS 
functional  requirements  have  been  satisfied  (e.g.,  that  correct  inputs  yield 
correct  results).  Functional  testing  shall  include,  in  part: 

a.  the  transfer  and  processing  of  transactions  (e.g.,  messages, 
interrupts,  data  base  subsets)  through  the  different  CIs; 

b the  transfer  of  messages  across  the  CDS  external  interfaces; 

c.  tests  of  hunan  operators  interfacing  with  the  CDS  equipment;  and 

d.  exercise  of  the  system  deployment  options  (paragraph  5. 1.5*1. 5). 

•5. 1.*.2. 2 PBC  A10513.  System  performance  Testing.  Conduct  tests  of 
each  Function  defined  in  the  CDS  System  Specification  under  each  workload 
there  prescribed,  to  verify  the  system's  ability  to  correctly  complete  each 
Function  within  its  required  response  times.  Conduct  saturation  tests  of  each 
applicable  subset  of  these  functions,  as  defined  in  the  CDS  System 
Specification,  to  predict  realistic  CDS  <0.  rload-fcaadling  capacity  limits. 

BOTE:  The  CDS  System  Specification  is  presumed  to  contain  well-defined 

quantitative  system  performance  requirements  for  each  of  a representative  set 


42 


of  workloads  also  well-defined  there , including  workloads  representative  of 
all  critical  operation*!  situations.  In  aggregate,  these  workloads  should 
thoroughly  expose  CDS  systew  capacity.  The  corresponding  quantitative 
performance  requireaents  should  have  been  established  as  feasible,  as  well  as 
needed,  during  Validation  Phase  simulation  and  analysis  (see  LCEG,  Section 
*.3-2). 

5.1.4.2.3  a C 11Q51C.  Reliability.  MsinUinabillty  * Availability 
Testing . Conduct  tests  supplementary  to  those  performed  under  the 
Reliability,  Maintainability,  and  Availability  ta\sks  (see  paragraphs 
5.1.5.1.10,  5.1.5.1.11,  and  5.1.5.1.20).  These  tests  shall  establish  whether 
observed  CDS  Reliability,  fSaictXi  inability,  Availability  and  Probability  of 
Success  values  are  within  thsiv  CDS  Srstem  Specification-defined  limits. 

•5.1. *. 2. A pbc  aiosid.  Testify , Perform  inspections, 

analyses,  demonstrations , and  tests' , per  the  System  Test  Plan  and  the  System 
Security  Plan,  to  verify  the  system's  ability,  as  prescribed  in  the  CDS  System 
Specification,  to  accept,  store  and  route,  without  compromise  and  without 
violation  of  other  specified  requirements,  multi-level  classified  traffic 
including  Top  Secret 

ROTE:  The  security  requirements  or  the  CD'  and  its  components  are  presumed 

defined  ss  part  of  the  Allocate  Baseline  and  the  CDS  System  Specification. 
However,  the  contractor  should  also  be  required  to  prepare  a Security 
Subsystem  Design  Analysis  Report  so  identify  the  specific  criteria  for  test 
and  evaluation  of  the  security  controls,  and  to  summarize  these  criteria  in  a 
CP  DP  update.  This  requires  the  development,  verification,  and  documentation 
of  a precise  description,  or  model,  of  the  security  controls,  and  an 
allocation  and  precise  specification  of  those  controls  to  Computer  Program 
Components  (CPCs).  The  contractor  should  also  be  required  to  carry  out  and 
fully  document  analyses  and  tests  n'.icfc  completely  verify  that  the  design  and 
implementation  of  the  security  controls  meet  the  requirements  of  the  model. 
Detailed  direction  to  the  contractor  must  be  provided  as  part  of  the  SOU.  In 
addition,  appropriate  and  timely  Government  visibility  into  the  contractor's 
security  controls  design  and  verification  process  must  be  specified.  Careful 
attention  to  explicit  detail  in  the  preparation  of  the  SOU  in  this  area  can 
substantially  r<*4uce  the  security  certification  risk  and  potential  delay.  The 
ellipses  (i.e.,  *...")  in  model  SOU  paragraph  5.1. A. 2. A and  in  paragraph 
5.1.5.1.15  indicate  appropriate  points  for  insertion  of  such  requirements. 

5.1.  A. 3 PBC  A1053.  Operational  Test  4 Evaluation  (OTAE).  Support 
Initial  OTAE  (10T4E),  to  be  conducted  by  an  Air  Force  Test  Teas  in  three 
phases,  as  defined  in  the  TEKP.  Provide  equipment  maintenance,  software 
maintenance,  and  operator  support,  plus  all  needed  documentation,  consumable 
materials  and  spare  parts,  during  each  phase  defined  below. 

5.1.  A. 3a  Phase  1.  Schedule  forty  hours  of  CDS  time  for  Phase  1 IOTAE 
sessions  in  1-2  hour  blocks  among  intervals  of  System  Functional  Testing 
(paragraph  5.1. k. 2.1).  Identify  these  blocks  in  a master  test  scheoule  and 
notify  the  Government  of  each  at  least  two  working  days  before  the  block  is  to 
become  available.  The  Government  will  use  these  blocks  mainly  for  initial 
familiarization  with  the  CDS. 
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5* 1.4. 3b  jBtfSfi  2.  After  successful  System  Functional  Testing,  provide  a 
period  of  ten  consecutive  wonring  days  during  which  the  Government  will 
operate  the  CDS.  Provide  the  saae  configuration  of  CDS  equipment  and  software 
used  by  the  contractor  to  perform  successful  System  Functional  Testing. 

During  the  10-day  period  the  Government  will  test  the  CSS'  human  interfaces. 
Should  the  configuration  become  unavailable  for  any  reason  during  the  10-day 
period,  extend  Phase  2 at  no  change  in  contract  terms  Tor  the  period  it  was 
unavailable. 

5.1. A. 3c  Phase  3.  Upon  successful  conclusion  of  DT4E  the  Government 
will  conduct  30  consecutive  working  days  of  I0TAE.  Provide  for  the 
Government's  use  the  complete  operational  CDS  equipment  and  software 
configuration.  Should  the  configuration  become  unavailable  for  any  reason, 
extend  Phase  3 at  no  change  in  contract  terns  for  the  time  the  configuration 
was  unavailable. 

MOTE:  I0T4E  planning  and  conduct  is  presumed  accomplished  by  the  Using 

roamunrl  and  the  Implementing  Command,  based  on  the  TEMP  (see  LCE&,  Section 
A 4.3). 

5- 1.4. 4 PEC  ^1056.  Test  A Evaluation  Supooirt.  Provide  the  services, 
documentation,  spare  parts,  special  instrumentation,  consumable  materials,  and 
other  items  needed  to  operate  and  sain  tain  the  CBS  during  all  CDS  System  Test 
and  Evaluation  periods. 

•5- 1-4.5  PBC  A1Q57.  Teat  Facilities.  See  paragraph  5- 1-7. 

•5.1.5  PBC  A1Q60.  System  Program/ Project  Hanaitemcnt 

Perform  all  functions  necessary  to  the  technical  control,  support 
engineering,  and  business  management  of  the  contract.  Plan,  direct,  and 
control  the  developeent,  assenbly,  integration,  and  testing  of  the  CDS  to 
assure  that  its  requirements  are  met.  Coordinate  and  assure  the  adequacy  and 
consistency  of  the  tasks  performed  under  paragraphs  5.1.1  - 5- 1.4.5  and  5.1.6 
- 5. 1.7.4  and  their  subparagraphs.  This  task  excludes  systems  engineering  and 
prograa  sanagecent  effort  devoted  explicitly  to  Level  3 and  lower-level 
Elements  of  the  Prime  Mission  Product. 

•5. 1-5.1  PBC  A 1061.  Systems  Engineering  Management.  Perform  the 
Systems  Engineering  management  and  Systems  Engineering  activities  necessary  to 
implement  the  technical  requirements  of  the  contract,  including  the 
Specifications,  the  CDHL,  this  SOW,  the  Delivery  Schedule,  and  the  contract's 
other  technical  attachments.  Provide  maximum  Systems  Engineering  support  to 
software  development  and  acquisition,  integration,  test,  and  documentation. 
Plan,  direct,  and  control,  in  accordance  with  the  Government-approved  SEMP,  a 
totally  integrated  er*  ineering  effort,  including  Design  Engineering,  Specialty 
Engineering,  Security  Engineering,  System  Analysis  and  Test  Engineering. 
Maintain  the  CDS  System  Specification  consistent  with  Government-approved  CWBS 
extensions  and  Government-approved  design  changes.  Maintain  the  CPDP,  the 
SEMP,  the  GFP  System  Design  Aids  CPCI  (paragraph  5-1. 1-3-9)  and  its 
documentation  per  Government  direction.  This  task  encompasses  system  design 
optimization  (including  Cost  Effectiveness  Analysis),  intrasyste®  and 
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intersystec  compatibility  analysis,  systes  security  analysis,  System  Failure 
and  Recovery  Analysis,  and  Syste*  Throughput  and  Response  Tine  Analysis. 

•5- 1.5.1.'  System  Failure  A Recovery  Analysis.  Based  on  the  contract's 
Specifications,  results  of  tr.e  Reliability  Program,  (paragraph  5. 1.5. 1.10), 
results  cf  tr.e  Maintainability  Program  {paragraph  5. 1.5.  ■«.  1 1 ) , results  of  rh® 
Computer  Pregrass  task  (paragraph  5. 1-1-3),  and  results  of  the  Integration  1 
Assembly  task  (paragraph  5-1.1.*),  develop,  maintain,  oociment  and  employ  2 
systes  failure  and  recovery  aodel  to  store,  calculate,  and  display,  for  earn 
■ode  of  CDS  failure:  unique  failure  aode  identification;  probability  of 

occurrence;  possible  causal  aechaniss(s) ; effects  on  the  systes  before 
reconfiguration;  sethod(s)  cf  detection;  estimated  detection  tise(s); 

■ethod(s)  of  immediate  reconfiguration  (e.g.,  to  a degraded  rode  of 
operation);  estimated  tiae(s)  needed  to  recovery  full  capability,  including 
reconfiguration,  data  base  restoral,  and  computer  prog ran  rerun  times; 
■etnod's)  of  restoring  such  full  capacity;  and  any  systes:  down  tiae  entailed 
in  such  restoral.  Cocucent  the  results  in  periodic  Technical  Reports.  Keep 
computer  progras  developeent  personnel  aware  of  all  design  probless  exposed 
and  all  suggested  design  improvements , as  these  are  discovered.  Monitor 
development  A integration  of  all  Cls  A FAs  to  assure  satisfaction  of 
requirements  related  to  detection  A recovery’  free  failure.  Provide  input  to 
the  Availability  analyses  (paragraph  5-1.5-1-20). 

MOTE:  A task  of  tnis  kind  should  be  included  in  the  prime  contract  SOL-  for 

Full-Scale  Development  of  every  system  with  complex  failure  nodes.  Ideally, 
such  analyses  should  oe  well  underway  by  the  end  of  the  Validation  Phase,  ar.c 
applied  during  Validation  Phase  systes  design  verification  (see  LCEG,  Section 
*.3.2).  If  so,  the  nod el  should  be  imposed  on  the  pri*e  Full-Scale 
Development  Phase  contractor  as  GFP,  and  his  SCfc  should  provide  for  his 
■aintenance,  extension,  and  use  of  it.  If  the  >cdel  is  iapleaented  as  a 
computer  program,  it  must  be  so  defined  in  tne  SOW  and  the  CDRL. 

•5. 1.5. 1.2  Tnroughput  A Response  Tiae  Analysis.  Continue  and  extend  the 
Government-furnished  Validation  Phase  Throughput  A Response  Ti»e  Analyses 
(used  to  validate  the  CDS'  Authenticated  Syste*  Specification  and  Allocated 
Baseline),  to  reflect  the  further  detailing  of,  and  changes  to,  the  syste* 
design  during  Full-Scale  Developaent.  Learn  the  Goverwaent-furnished  Systes 
Perfcraance  Simulation  Progras  (SPSP),  a discrete-event  simulator  which  is 
part  of  the  Systea  Design  Aids  Cl.  Study  the  related  Govertwent-furnished 
technical  reports  describing  the  methods  and  limitations  of  these  analyses  me 
their  results.  Modify  the  SPSP  to  reflect  both  further  design  detail  and 
higher-level  changes  in  both  systes  design  and  in  prescribed  workloads, 
wherever  such  changes  could  affect  CDS  throughput  or  response  times.  Keep  a 
SPSP  Version  consistent  with  the  Systea  Design  Data  Base  wherever  the  latter 
changes „ as  prescribed  in  paragraph  5. 1.5.1. 3*  Exercise  the  SPSP  to  ascertain 
the  effects  of  such  changes.  Similarly,  predict  the  effects  of  proposed 
changes  as  a basis  for  their  consideration.  Supplesent  use  of  the  SPSP  by 
appropriate  mathematical  analyses.  Control  any  changes  to  the  SPSP  and  its 
documentation  per  the  ;roc2dures  defined  in  the  CPDP.  Keep  the  SPSP  and  its 
documentation  consiste:  t,  and  in  good  condition.  At  specific  Government 
request  provide  up  to  'ive  designated  Government  personnel  with  *achine- 
readable  copies  of  eaci  SPSP  Version,  and  its  documentation,  for  their  own 
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use.  Provide  periodic  briefings  and  Technical  Reports  explaining  CPS? 
changes,  methods  of  analysis  ana  current  sjrstcc  performance  predict  lens.  At 
Government  re-juest,  analyte  hypothetical  changes  in  system  configuration, 
workloads,  and  use.  Provide  current  predictions  of  response  (i.e. 
th.  .ugh pul,  c los  ;'cr  each  CDS  Svstee  foecif icatiow-defined  Function, 
required  by  the  Availacility  task  (paragraph  5.1-5.1.20). 

*9It:  The  continued  use  throughout  the  Full-Scale  Development  Phase  of  the 

performance  sir-iation  and  analysts  techniques  developed  during  the  Validation 
Phase  is  st rcc£>/  recommended  os  ih'  most  effective  way  normally  available  to 
predict  ar.d  c^-rvct  system  performa-.ee  prcblems  as  early  as  possible.  To  wait 
to  cetect  such  problems  until  system-level  DTAE,  or  until  IOTAE,  risPs 
unnecessarily  r.i~r.  costs  for  major  redevelopment  effort.  To  allow  a Full- 
Scale  Development  Phase  contractor  to  discard  proren  Validation  phase 
iectniques.  and  to  substitute  his  own,  risks  new  performance  predictions  that 
are  difficult  to  verify  and  u,  compare  with  known  results. 

•5- 1-5- 1.3  System  Design  Ad  iustaent  A Wiintenance.  Adjust  the 
aliocati'  •e;uiresents  & computer  resources  among  the  system's  FAs,  CIs,  4 
Computer  "“Cgrar  Components  (CPCs)  as  necessary  to  eliminate  predicted 
perfen sa  prcblems,  to  enhance  testability,  or  to  allow  successful 

implementation.  Use  tne  SPSP  (see  paragraph  5. 1.5. 1.2)  to  explore  the  effects 
of  pc tent la 1 allocation  changes.  Such  adjustment  will  require  Government 
approval  when  it  entails  changing  baselined  specifications.  Maintain  and 
extend  the  GFP  System  Design  Data  Base,  using  the  GFP  System  Design  Data  Base 
Management  Program  to  represent  correctly  all  changes  to,  and  further 
detailing  cf,  the  CDS  system  design  subsequent  to  contract  award.  (Both  the 
System  Design  Data  Base  and  the  System  Design  Data  Base  Management  Program  are 
part  of  the  Syrtem  Design  Aids  Cl.)  For  each  CPCI  and  CPC  for  which  an 
Extendea  CWcS  Element  (see  paragraph  5- 1-5-2. 1.1)  is  defined,  ir~:rpcrate  in 
the  Syste*  Design  Data  Base  the  computers  the  programming  language,  the 
current  estimated  (or  verified)  size,  execution  time,  Versior,  computer 
Program  Life  Cycle  Phase,  and  test  status  (i.e.,  total  number  of  tests: 
defined,  currently  passed,  currently  failed,  and  currently  pending).  Using 
the  System  Design  Data  Base  Management  Program  as  an  aid,  prepare  periodic 
Technical  reports  depicting  graphically  and  in  tabular  for*  the  current  system 
design  and  its  estimated  development  status.  Reflect  all  approved  design 
changes  i.\  CDS  System  Specification  revisions,  in  Development  Specification 
revisions,  or  in  addenda  to  the  correspond ing  commercial  specifications,  for 
CIs  that  la.-,  "evelopsent  specif  ications) , and  in  Product  Specif icati-»n 
revisions. 

liOTE:  S^e  paragraph  5- 1-5-2. 1.1  and  it's  note  for  explanation  of  the 

recommended  ievelcpeent  CPCI  C*BS  Element  breakdown  and  for  the  uses  of  the 
corresponding  cost  and  sizing  data. 

•5. 1.5-1- ft  Planning  for  Change.  Plan  to  accommodate  CDS  workload 
increases  and  decreases,  and  other  requirements  changes,  as  the  need  arises. 
Assess  the  impacts  of  potential  workload  increases  and  design  changes  on 
system  performance  k integrity.  Identify  thresholds  for  equipment 
configuration  changes.  Design  changes  to  implement  new  requirements.  Assess 
th*  cos*,  ar.d  -.hedule  impacts  cf  proposed  design  changes.  Generate  Technical 
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import*  reflecting  these  analyses.  Prepare  Engineering  Change  Proposals 
(ECPs)  reflecting  reconaended  chafes.  Allocate  approved  changes  moag  future 
versions  of  the  CDS.  Idiot  a navlnun  of  six  nan-years  of  technical  effort  per 
year  to  this  task. 

V2X£:  This  paragraph  explicitly  recognizes  the  need  for  an  activity  to  assess 
to*  ieoact  of  proposed  new  requireaents  on  the  systen  design,  to  assess  other 
proposed  design  changes,  to  prepare  ECPs,  and  to  schedule  approved  changes  for 
aininml  iapact  on  system  development. 

5- 1.5. 1.5  for  Svstear  Deployment.  Plan  options  for  the 

scheduling  and  allocation  of  the  CDS'  resources  asong  its  users  to  provide 
then  acceptable  service  in  both  noncal  and  degraded  nodes  of  operation,  and  to 
aeet  the  CDS  System  Specification's  requireaents.  Plan  the  transitions  aaong 
these  aodes,  and  their  aan&geaent.  Incorporate  results  of  the  Systea  Failure 
A lecovery  Analysis  (paragraph  5-1-5. 1.1). 

5.1. 5.1-6  fhln^tnpnyr  If  necessary,  reorganize  tne  SEMP  to 

correspond  to  the  tasks  defined  by  paragraph  5- 1-5-1  and  its  subparagraphs. 
5p^te  and  sain  tain  the  SEMP  per  MIL-STD-*9SA(0SAF)  and  Governaent  direction. 

JK2£:  & CDRL  entry  aust  specify  delivery  of  the  SEMP  revisions. 

5- 1.5- 1-7  CP  DP  tfcint*«wy»e-  Complete,  update  and  sain  tain  the  CP  DP, 
subject  to  Governaect  approval  of  all  changes  (e.g.,  redefinition  or 
rescheduling  of  CPCI  Versions).  Manage  the  Coaputer  Programs  and  the 
Integration  A Assembly  tasks  (paragraphs  5- 1-1-3  and  5-1-1-*)  in  accordance 
with  th*  CP  DP. 

JKZXE:  The  CP DP , included  in  the  contractor's  proposal  and  made  a part  of  the 

contract,  is  presumed  to  contain  a complete  initial  definition  of  the  systea 's 
CPCI  Versions  and  their  delivery  dates.  A CDRL  entry  aust  provide  for 
preparation  and  delivery  of  each  CPCI  rersion,  and  another  CDRL  entry  for  the 
Version's  documentation  (e.g..  Version  Description  Documents).  Another  CDRL 
entry  must  specify  preparation  and  delivery  of  the  CP DP  revisions. 

*5- 1-5- 1-8  Svs teg  Deslm  Reviews.  Conduct  the  following  Systea  Design 
Reviews  (SDRs)  as  specified  in  KIL-STD-*99A(USAF)  paragraphs  10.1.6  A 
10-1.6-2,  and  in  KIL-STD-152KUSAF) , Appendix  B,  except  as  specified  below. 
Contractor  failure  to  complete  any  of  these  SDRs  to  the  Government's 
satisfaction  within  one  month  of  its  inception  shall  be  deeaed  sufficient 
ground  for  Governaent  termination  of  the  contract. 

•5-1.5-l.8a  Initial  SDR.  Conduct  an  initial  SDR  within  three  months  of 
contract  award  and  prior  to  any  CDS  Cl  PDRs.  The  initial  SDR  shall  assure 
contractor  understanding  of  the  Allocated  Baseline  and  review  the  contractor's 
overall  CDS  system  design  and  his  system  development  plans.  Governaent 
certification  that  this  SDR  has  been  coapleted  to  the  Government's 
satisfaction  shall  precede  continued  system  development. 

•5.1.5.1.8b  Intermediate  SDR.  Conduct  an  intermediate  SDR  after  all  CDS 
Cl  CDRs  have  been  conducted,  and  before  more  than  251  of  the  total  estivated 
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code  of  the  CPC  Is  to  be  developed  has  been  written.  This  SDR  shall 
demonstrate  by  analysis  the  system  design's  completeness,  consistency,  and 
ability  to  meet  all  ms  agjag  Specification  requirements. 

•5.1.5.1.80  Final  sot.  Conduct  a final  SM  after  completion  of  all  CSS 
CIs'  TCis  and  of  all  its  CPC Is'  PCAs.  The  final  SDR  shall  precede,  and  shall 
assure,  the  CSS's  readiness  for  syntax-level  testing. 

MOTE:  The  proposed  second  and  third  SDR  six  to  reduce  design  incompatibility 

axof%  the  system's  aany  components.  This  is  typically  a severe  problem  in  the 
development  of  large  systems  in  which  Cl-level  design  reviews  are  conducted 
sequentially  and  often  independently.  Also,  see  notes  under  paragraph  5.1.1b. 

5. 1.5. 1.9  Additional  Effort.  In  addition  to  the  tasks  prescribed  by 
other  subparagraphs  of  SOU  paragraph  5. 1-5-1,  perform  as  modified  below  the 
Systems  Engineering  effort  defined  in  the  indicated  paragraphs  of  MIL-STD- 


499AOJSAF): 

10.1.2 

prograa  Risk  Analysis 

10.1.4 

Decision  and  Control  Process 

1C. 1-5 

Technical  Performance  Measurement 

(TPM) 

10.1.5.1 

Parameters 

10.1.5.2 

Planning 

10.1.5-3 

Implementation  of  TPM 

10.1.5-4 

Relating  TPM  to  Cost  and  Schedule 

9 

1 

*> 

% 

t 

10.1.6 

Technical  Reviews.  Substitute  "co-chairman  with  the 
Government"  for  "chairman"  in  the  third  sentence. 

10.1.6-3 

Preliminary  Design  Review 

10.1.6.4 

Critical  Design  Review 

10.1.7 

Subcon tractor/ Vendor  Reviews 

10.1.8 

tfork  Authorization 

10.1.9 

Documentation  Control 

10.2.4 

Synthesis 

10.2.6 

Life  Cycle  Cost  Analysis 

10.2.7 

Optimization 

10.2.7.1 

Trade-off  Studies 
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10.2.7.2  System/ Cost  Effectiveness  Analysis 

10.2.7.3  Effectiveness  Analysis  Modeling 

Perform  the  Technical  Perfornance  Measurement  activities  (KIL-Sn>-A99A(USAF) 
paragraph  10.1.5  and  its  subparagrapos)  consistent  with  the  related  activities 
defined  in  SOU  paragraph  5- 1-5.1  and  its  other  subparagraphs,  avoiding 
duplication  of  effort. 


BPTE:  This  nodsl  SOU  paragraph  illustrates  incorporating  provisions  of 

Regulations , Specifications , and  Standards  by  reference.  This  is  easy  but 
potentially  dangerous,  as  discussed  in  guidebook  Section  3.2. 


5.1.5.1-10  PBC  A1061A.  Reliability.  Plan  and  implement  a Reliability 
Prog ran  covering  all  developed,  purchased  and  GFP  equipment  in  accordance 

with Identify  and  report  all  equipaent  failure  aodes  that  could  cause  any 

fora  of  system  failure,  breach  of  systea  integrity,  or  breach  of  systea 
security.  Estimate  the  probability  of  each  such  failure  node  A state  how  it 
can  be  detected  aanually  or  automatically. 

BOTE:  Development  of  failure  node  data  under  the  Reliability  and  the 

Ihintainability  tasks  is  prerequisite  to  their  use  in  effective  System  Failure 
A Recovery  Analysis  (see  paragraph  5-1-5- 1.1),  and  in  the  design,  development, 
and  assessment  of  system  failure  A recovery  procedures  {see  paragraph 
5. 1.5. 1.5,  Planning  fnr  System  Deployment)  and  software. 

5-1-5.1.11  PBC  A 106 IB.  Maintainability.  Plan  and  implement  a 

Maintainability  Program  in  accordance  witn....  Identify  and  report  for  each 
equipment  failure  mode  the  appropriate  type(s)  of  preventive  and  corrective 
maintenance,  the  estimated  mean  repair  time(s),  and  haw  the  repaired  (or 
replaced)  equipment  would  be  reintroduced  into  the  CDS  configuration. 

BOTE:  Development  cf  failure  mode  data  under  the  Reliability  and  the 

Maintainability  tasks  is  prerequisite  to  thair  use  in  effective  System  Failure 
A Recovery  Analysis  (see  paragraph  5. 1.5. 1.1),  and  in  the  design,  development, 
and  assessment  of  system  failure  A recovery  procedures  (see  paragraph 

5. 1-5- 1-5,  Planning  for  System  Deployment)  and  software. 

5-1-5.1.12  PBC  A1061C.  Parts  Control. 

5.1.5.1.13  PBC  A1061D.  Nomenclature. 

5. 1.5. 1.1*  PBC  A1061G.  Elec* tic  Compatibility. 


5.1-5.1-15  PBC  A1061J.  Security.  Plan,  establish,  and  maintain  a 
Security  Engineering  Program  to  meet  the  system's  security  requirements  as 
defined  in  the  CDS  System  Specification.  Develop  a corresponding  System 
Security  Plan.  Perform  and  document  a Clandestine  Vulnerability  Analysis. 
Prepare  a System  Security  Standard 

ROTE:  See  note  under  paragraph  5.1. A. 2. 
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5.1.5.1.16  PBC  A1061K.  Sunrivability/TuinermbilitT. 

5.1.5.1.17  PBC  11061L.  System  Safety. 


5.1.5.1.18  PBC  A1061M. 


5.1.5.1.19  PBC  A1061F.  Value  Bwtineerinm.  Develop  a Value  Engineering 
Plan  per  MIL-V-38352,  Value  Engineering  Program  Requirements.  to  establish, 

■a in tain,  control,  and  aonitcr  Value  Engineering  (VE)  throughout  the  CDS' 
lifetime.  Conduct  the  planned  VE  prograa  to  aaxinize  overall  CDS  operational 
utility  at  minimal  cost.  Identify  in  the  VE  plan  high-cost  areas  where  major 
VE  effort  will  be  applied.  Also  identify  any  redundant  tasks  or  subtasks 
prescribed  or  iaplied  under  terns  of  this  contract.  Conduct  VE  studies 
analyzing  the  potential  cost  savings  and  the  corresponding  estiaated 
performance  changes  likely  to  result  free  promising  CDS  requirements  changes 
and  design  modifications.  Prepare  and  submit  Value  Engineering  Change 
Proposals  (VECPs)  per  Armed  Services  Procurement  Regulation  (ASPR)  7-lW.*ib, 
included  in  this  contract's  General  Provisions.  Generate  VE  progress  reports 
per  HIL-V-38352,  paragraph  3-5-2. 


•5-1.5.1.20  PBC  A10610.  Availability.  Establish  and  maintain  a data 
base  of  facte rs  necessary  to  compute  Inherent  Availability,  Observed 
Availability,  Inherent  Probability  cf  Success,  and  Observed  Probability  of 
Success,  as  defined  in  the  CDS  System  Specification.  Obtain  these  factors, 
and  changes  to  thee,  from  the  results  of  the  Reliability,  Maintainability, 
System  Failure  A Recovery  Analysis,  and  Throughput  A Response  Time  Analysis 
tasks.  Compute  an  Inherent  Availability  and  an  Observed  Availability  for  the 
CDS  as  a whole,  for  each  FA,  and  for  each  different  other  portion  cf  the 
system  used  to  perform  CDS  System  Specification-defined  Functions.  Compute  an 
Inherent  Probability  of  Success  and  an  Observed  Probability  of  Success  for 
ea ;n  such  Function,  based  respectively  on  the  Inherent  Availability  and  on  the 
Observed  Availability  of  the  subset  of  CDS  equipment  needed,  and  on  the 
predicted  'or  observed)  time  required,  for  the  system  to  perform  the  Function, 
considering  both  normal  and  failure-recovery  situations.  Compare  the  results 
of  these  calculations  with  the  corresponding  quantitative  performance 
requirements  stated  in  the  CDS  System  Specification.  Incorporate  the  result* 
in  monthly  Technical  Performance  Measurement  Reports.  Use  the  results  in 
design  optimization.  Cost  Effectiveness,  and  system  integrity  analyses. 

5. 1.5.2.  PBC  A1062.  Supporting  Project  Management  Activities. 

Designate  a full-time  Prog ran  Manager  to  insure  proper  control  and 
coordination  of  the  work  performed,  consistent  with  the  contract  requirements. 
Wherever  pertinent,  provide  effective  organizational  interfaces  between 
software  activities  and  other  management  and  engineering  activities.  Insure 
that  any  subcontractor  and  vendor  products  and  services  comply  with  the 
appropriate  subset  of  this  contract's  requirements.  This  task  includes  all 
contract  management,  cost  A schedule  management,  business  and  administrative 
planning,  organizing,  directing,  coordinating,  controlling,  and  approval 
actions  designed  to  accomplish  overall  project  objectives  wnich  are  not 
included  under  Systems  Engineering  Management  (paragraph  5. 1-5-1).  This  task 
excludes  related  activities  explicitly  required  to  prepare  Elements  of  the 
Prime  Mission  Product. 
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5. 1-5.2- 1 PBC  A 10621.  Prow—  Wan— ament.  Per  the  Government-approved 
general  approach  submitted  as  part  of  the  contract  proposal,  plan,  organize, 
direct,  coordinate,  control,  and  approve  actions  of  contractor  personnel  as 
necessary  to  accomplish  overall  prog ran  objectives.  Keep  contract  planning, 
■anagenent,  status  reporting,  awl  cost  reporting  consistent  with  the  Extended 
CUBS  (see  paragraph  5- 1-5.2. 1.1).  Conduct  monthly  program  reviews  alternately 
at  the  contractor's  and  at  the  Government's  facilities.  For  each  monthly 
program  review  generate  Presentation  Material  that  covers  technical  status, 
threat  status,  schedule  status,  problems,  software  development  status, 
reliability,  tradeoffs,  and  other  significant  activities.  Include  in  the 
briefing  charts  for  each  program  review  a current  organi:ation  chart  that 
incorporates  the  names  of  all  key  personnel  anu  any  key  personnel  changes. 

5.1.5.2.1a  Management  System.  Approximately  thirty  days  after  contract 
award,  demonstrate  to  the  Government  the  contractor's  management  systems  that 
will  be  used  to  insure  the  traceability  and  visibility  required  for  effective 
management  of  the  contract  effort.  Those  management  systems  shall  provide  the 
Government  each  month  with  the  data  required  to  assess  actual  versus  planned 
accomplishment  with  respect  to  completion  of  work  within  mutually  agreed  cost 
A scheduled  goals.  Deviations  from  these  goals  shall  require  monthly  reports 
on  the  problems,  tdiich  describe  remedial  actions  and  expected  dates  of 
solution.  Report  work  completion  information  monthly  in  Program  Milestones 
and  Cost  Performance  Reports.  The  Program  Milestones  shall  report  on  the 
Elements  of  both  the  Delivery  Schedule  and  the  CDRL.  Generate  monthly  a 
Configuration  Index  (Computer  Program)  and  a Change  Status  Report  (Computer 
Program)  for  each  CPCI. 

BOTE:  Contractor  reporting  of  development  status  has  been  barely  satisfactory 

in  seme  previous  acquisition  programs.  Typically  the  information  reported  is 
6-8  weeks  old  when  received  by  Program  Office  technical  monitoring  personnel, 
and  may  also  reflect  biased  contractor  views  on  the  status  of  questionable 
items  (e.g.,  tdsether  the  contractor  has  satisfactorily  completed  a 
controversial  PDR  action  item).  Thus,  in  lieu  of,  or  in  addition  to,  the 
monthly  status  reporting  prescribed  in  this  model  SOU  paragraph,  a Program 
Manager  should  consider  having  his  own  computer-based  status  accounting 
system.  Of  course,  careful  Government  monitoring  of  the  contractor-provided 
portion  of  this  system's  input  data  would  be  essential  to  its  success. 

BOTE:  In  addition  to  conventional  status  data,  consideration  should  be  given 

to  requiring  contractors  to  report  aontihly  the  types  of  information  about 
personnel,  coding  A documentation,  development  facility  use,  and  other 
facilities,  listed  in  ESD-TR-75-85,  An  Air  Force  Guide  for  Monitoring  and 
Resorting  Software  Development  Status.  Appendix  III,  Section  12,  as  aids  to 
realistic  assessment  of  software  development  status.  If  (in  contrast  to  this 
model  SOB)  a software  development  contractor  should  be  required  to  establish  a 
Programing  Support  Library  (PSL)  as  defined  in  Volumes  V,  VI,  and  IX  of  RAPC- 
TR-7A-300,  Structured  Progr*—  igg  Series,  his  SCV  should  also  require  his 
reporting  PSL  data  coaparable  to  the  above. 

•5- 1.5-2. 1.1  PBC  A1062AA.  Prograc/Cont ^act  Work  Breakdown  Structure. 
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•5. 1-5-2. 1.1*  CWBS  Updating.  With  Government  approval,  update  the  CUBS 
(extended  as  defined  below) , to  reflect  any  contractual  chafes  or  Goverawnt 
direction  that  say  occur  during  performance  of  this  contract  which  affect  the 
definition  of  supplies  or  services  provided  under  it.  Keep  the  CUBS 
consistent  with  the  overall  CBS  program's  Summary  program  Breakdown  Structure 
(PBS).  Recommend  to  the  Government  appropriate  PBS  chaises. 

•5.1.5.2.1.1b  CtfBS  Extension.  Extend  the  CUBS  and  its  Dictionary  to 
lower  levels  during  performance  of  this  contract  to  provide  concrete  cost 
accounting  data  consistent  with  the  contractor's  Government-approved 

Cost/Schedule  Control  System  (see  paragraph  5- 1.5.2. 1.3) Define  a 

separate  Extended  CUBS  Element  (and  a corresponding  Extended  CUBS  Dictionary 
entry)  for  each  distinct  combination  of: 

a.  each  CPC  of  each  CPC I to  be  developed  (see  paragraph  5.1.1.3a);  and 

b.  each  of  the  six  phases  (i.e. , Analysis,  Design,  Coding  and  Checkout, 
Test  and  Integration,  Installation,  and  Operation  and  Support)  of 
the  Computer  Program  Life  Cycle. 

Define  the  Computer  Program  Life  Cycle  phase  boundaries  identically  for  all 
CPCIs,  consistent  with  AFR  8 00-1 A,  Acquisition  and  Support  Procedures  for 
Computer  Resources  in  ¥ol . II,  paragraphs  2-8  and  5-2  through  5-5. 

BOTE;  See  the  notes  following  paragraph  5. 1.5.2. 1. 1e. 

•5.1.5.2.1.1c  Supplementary. Computer  Programs  Cost  Breakdown.  In 
addition,  provide  the  following  supplementary  breakdown  of  all  software- 
related  effort  and  costs  across  the  entire  CDS: 

PBC  Supplementary  Software  c» teynrw 

4210  Computer  Programs  (analysis,  design,  coding,  checkout: 
purchase  or  rental  costs  only) 

4220  Software-peculiar  training 

4240  Equipment  needed  specifically  for  software  development 
or  maintenance 

4250  Testing  of  software 

4260  Software-peculiar  management  and  engineering 

4270  Software  documentation 

4285  Software  development  and  maintenance  facilities 

4290  Other  software-related  costs 

4200  Summary  of  all  software-related  costs 
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Provide  this  breakdown,  by  CFCI  i*ere  appropriate,  in  adaition  to  the  standard 
breakdown  defined  in  the  Extended  CUBS.  Wbwever  software-related  activities 
share  facilities,  supplies,  or  services,  used  to  develop  other  portions  of  the 
CBS,  apportion  the  costs  of  these  shared  facilities,  supplies , or  services 
equitably  among  Computer  Programs  sod  their  ether  us*s , per  Goverment- 
provided  guidelines. 

*5. 1-5-2. 1. Id  PBC  Assignment.  Assign  ?BCs  to  all  extensions  of  the  CUBS 
per  ... 

BOTE:  The  ellipsis  (i.e.,  *...")  should  be  replaced  in  an  actual  SOU  by  thi3 
guidebook's  Tab!**  A- 3 plus  specific  direction  as  to  its  application  (see 
Section  A3). 

•5. 1.5-2. 1. 1e  Government  Aonror;!.  All  CUBS  extensions,  PBC 
assignments,  and  other  changes , and  apportioning  of  shared  costs,  whether 
contractor-proposed  or  Government-directed , shall  require  specific  Government 
approval . 

BOTE:  These  provisions  for  CUBS  updating,  extension  and  supplementary  cost 

breakdown  are  oad>*  to  support  collection  of  accurate  and  relevant  software 
cost  data  throughout  the  perforrance  of  the  contract.  Such  information  (e.g., 
the  composition  of  CPCIs  to  be  develoDed)  nay  be  unkuown  when  the  contract  is 
negotiated  or  say  subsequently  change. 

MOTE:  The  definition  of  cost  accounting  categories  for  the  CPCs  is 

recommended  as  an  initial  step  to  accumulate  a data  base  of  software 
develt..\aent  performance  data  that  can  be  applied  across  contracts  fer  more 
accurate  cost  estimation  and  quality  control.  Besides  cost  data,  information 
about  each  CPC's  programming  language,  computer,  size,  execution  time, 
development  time,  and  test  history  should  also  be  collected  (see  paragraph 
5. 1-5. 1.3).  This  information  should  oe  centrally  collected,  evaluated,  and 
disseminated  to  the  Software  Directors  of  all  Program  Offices  acquiring 
systems  that  include  software.  As  data  from  several  acquisition  programs  is 
accumulated  and  analyzed,  standard,  comparable  software  type  categories  should 
be  established  for  all  systems.  Where  comparab.e  data  cannot  be  collected  at 
the  CPC  level,  further  breakdown  of  CPCs  will  be  necessary. 

MOTE:  The  Air  Force  should  soon  establish  precise  standard  definitions  of  the 

Computer  Program  Life  Cycle  phases  to  facilitate  coaparison  of  development 
costs,  schedules,  and  technical  performance,  since  the  AFB  800-14,  Pol.  II 
definitions  are  somewhat  vague.  When  such  better  definitions  become 
available,  SOWs  should  prescribe  their  use,  rather  than  directing  contractors 
to  define  the  phase  boundaries,  even  with  Government  concurrence. 

MOTE:  Cove»vi*ent  approval  of  all  Extended  CWBS  Element  definitions  is 

prescribed  in  the  aodel  SOW  to  facilitate  specification  of  useful  cost 
accounting  categories,  comparable  across  systems.  Central  coordination  of 
such  categories  is  essential  to  the  collection  of  comparable  data  during 
different  acquisitions.  For  ESD-managed  programs,  the  Cost  Analysis  Division 
(ACC)  is  responsible  for  this  coordination. 
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5. 1-5-2. 1.2  PBC  11062AS.  Cost  Inforstatlon  System. 


*5- 1.5-2. 1.3  PBC  A1062AC.  Cost  Schedule  Sv sterna.  Control  cost  A 
schedule  performance  measurement  using  a single,  formal,  integrated 
Government-approved  systea  with  a common  data  base  that  will  serve  both  the 
contractor's  internal  management  requirements  and  the  Government's  needs  for 
cost  information,  as  these  are  specified  in  *;he  contract  and  elsewhere  in  this 
SOW  (see  paragraphs  5- 1-5.2. 1.1  and  5- 1-5- 1.3).  Use  the  Extended  CWBS  as  a 
framework  for  this  management  systea.  Generate  monthly  Cost  Performance 
Reports  for  each  Extended  CWBS  Eleaert. 

5. 1.5.2. 1.*  PBC  A1062AP.  Life  Cvcle  Costs.  Establish  and  maintain  a 
Life  Cycle  Cost  (LCC)  p v -am  as  defined  below.  The  LCC  program  shall  aim  to 
control  development  of  a •-.'S  able  to  meet  all  its  technical  requirements  at 
minimum  LCC.  and  within  the  contract-specified  LCC  goal....  Estimate  for  each 
CPC1  the  cost  elements  required  by  the  Government-furnished  LCC  Model,  and 

document  the  specific  estimating  methods  used Compute  monthly  LCC 

estimates  for  the  CDS,  each  Cl  ar.d  each  FA,  using  the  LCC  Model Conduct  an 

LCC  review  as  part  of  the  monthly  program  management  review  (see  SOW  paragraph 

5. 1-5.2. 1).  At  each  LCC  review  report  current  cost  and  per,-- nsance  estimates, 
and  identify  all  changes  from  the  previous  month's  LCC  estimates.  Explain  all 
differences  in  assunptions,  estimation  methods,  and  other  factors  that  account 
for  the  differences....  Assure  that  all  engineers  and  managers  understand  the 
LCC  program's  goals,  its  methods,  and  their  own  LCC-related 
responsibilities....  Identify  and  report  the  impact  on  LCC  of  each  related 
set  of  Engineering  Change  Proposals. 

5. 1.5.2. 1-5  PBC  A1C62AE.  Schedule  Management.  See  paragraph  5- 1 -5-2- 1 . 

5. 1.5. 2. 2 PBC  1062B.  Manufacturing  Management. 

•5- 1-5-2. 3 PBC  A1062C.  Configuration  Management.  Appoint  a single 
manager  responsible  for  conducting  Configuration  Management.  Configuration 
Management  includes  all  effort  necessary  to  identify,  audit,  maintain,  and 
control  the  c'vnfiguratic''  of  CDS  equipment,  software,  and  .-elated 
specifications.  Prepare  a Configuration  Management  Plan  f CMP)  per  HIL-STD- 
$83(US4f),  Appendix  I,  def.  ting  the  contractor  organization  and  procedures  for 
Configuration  Management.  After  Government  approval  of  the  CMP,  establish  and 
maintain  a Configuration  Management  program  per  the  CMP  a:.d  MIL-STD-*83(USAF) , 
HIL-STD-A90,  Specification  Practices.  MI L- STD- 1 52 1 ( USAF ) , and  MIL-S-83$90. 
Maintain  a current  Functional  Configuration  Identification  (FCI)  and  Allocated 
Configuration  Identification  ( ACI } by  prepa- ing  ECPs  to  specifications,  and 
Engineering  Change  Orders  (ECOs)  to  Engineering  Drawings,  and  by  processing 
all  Government-approved  configuration  changes  against  the  CDS  System 
Specification,  the  Development  Specifications,  and  the  related  Engineering 
Drawings  incorporated  in  this  contract.  Develop  a Product  Baseline  comprising 
the  Government-approved  Product  Specifications  and  related  Engineering 
Drawings  prepared  under  this  contract  or  provided  as  GFP. 

5 . 1.5.2.$  PBC  1062D.  Integration  of  Analyses  and  Related 
Ccmouter  Support . 
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MOTE:  Hi*  anticipated  revision  (i.e. , Change  1)  to  ESDP  800-4  explains  this 

model  SOU  paragraph,  which  should  prescribe  the  automated  management 
information  tools  to  be  used  durir^  performance  of  the  contract. 

*5. 1-5- 2. 5 PBC  A1062E.  Quality/ Inspection Establish  and  sain tain  a 

Software  Quality  Assurance  (QA)  program  per  the  CP  DP  and  MIL-S-52779(AD) , 
Software  ftialitv  Assurance  Program  Requirements.  The  Government  reserves  the 
right  to  approve  the  contractor's  software  QA  procedures  and  to  verify  or 
perform  any  inspections  or  tests  that  it  deems  necessary.  Incorporate  in  the 
CrDP  the  Software  QA  Program  Plan  requirements  of  MIL-S-52779(AD)  paragraph 
6.2. l.e. 


5- 1-5-2. 6 PBC  A 10625.  STIBFO. 

5. 1.5- 3  PBC  A1063-  Integrated  Logistics  Support Store  and  account 

for  all  CPCIs  and  their  documentation  until  the  contract  terminates. 

5. 1.5.3. 1 PBC  A1063A.  Preope rational  SuddIy  Support. 

5. 1- 5. 3* 2 PBC  A1063B.  pacfr»fp>y  Comply  with  Section  C of  the 
contract,  and  with  Section  5 (Preparation  for  Delivery)  of  the  CDS  System 
Specification  and  of  each  Cl's  Development  Specification  (if  any)  and  Product 
Specification. 

5- 1.5. 3-3  PBC  A1063C.  Transportation. 

5.1.5- 3-A  PBC  A1Q63D.  Travel. 

5.1- 5. 3-5  PBC  A1Q63E.  Maintenance. 

5. 1.5. 3- 6 PBC  A1Q64G-  limited  Scares /Repair  Parts  Provisioning. 

5- 1.5. A PBC  A 1064.  Crew/Human  Factors.  Plan  and  conduct  a Human 
Factors  prog ran  per....  Perform  task  and  skill  analyses  to  identify  the  tasks 
required  to  operate,  exercise,  maintain , and  modify  the  CDS  equipment  and 
software.  Establish  the  skills  and  estimate  the  time  that  each  such  task 
entails.  Estimate  the  numbers,  skill  categories  and  skill  levels  of  the 
personnel  needed  to  perforr  each  task,  assuring  continuous  CDS  operation,  and 
Organic  Maintenance  by  Governeent  personnel.  Docunent  the  results  in  a Human 
Operator/Critical  Tasks  Analysis  Report.  Generate  a Positional  Handbook  for 
each  CDS  operational  position  and  maintain  it  to  reflect  all  pertinent  system 
changes  during  the  contract. 

5. 1.5-  4.1  PBC  A1064A.  Human  Engineering. 

5. 1.5.4  2 PBC  A1064C.  Manpower/ Personnel  Requirements. 

5- 1 5.4.3  PBC  1064D.  Busan  Factors  Test  A Evaluation. 

•5.1.6  PBC  A 1070.  lata 
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5.1.6a  Deliverable  Data.  Provide  the  Data  (e.g. , reports  and  aachine- 
readable  coaputer  storage  medir)  specified  in  the  CNL  included  in  the 
contract,  grantieg  the  Governaent  Onliaited  lights  to  then  as  specified  in 
ASFR  7-10*. 9,  livhts  in  Seta  and  Coaouter  Software.  Recoaaend  additions  to, 
and  deletions  froa,  the  CDRL.  Clumber  and  nark  per  MIL-S?D-*83(USAF) , Appendix 
IX,  all  Data  of  the  types  specified  therein.  Account  for  the  costs  of  this 
Data  in  the  categories  defined  in  paragraphs  5. 1.6.1  - 5.1.6.*  and  their 
subparagraphs.  For  each  Data  itea  (specified  by  a CDRL  entry)  this  task 
includes  only  the  effort  that  can  be  reduced  or  cliainated,  or  that  will  not 
be  incurred,  if  the  Data  Itea  were  eliminated.  The  task  includes  the  effort 
to  acquire,  write,  asseable,  reproduce,  package  and  ship  Data  Iteas  with  their 
CDRL-prescribed  content  and  format.  The  task  also  includes  the  effort 
necessary  to  reformat,  reproduce,  and  ship  any  Data  obtained  froa  the 
contractor's  our<  records  or  froa  coaaercial  sources,  but  required  by  the  CDRL 
in  a different  foraat. 

5.1.6b  Data  Management  Organization.  Establish  a single  organization, 
and  designate  a priae  focal  point,  for  Data  management  activity.  Develop  and 
sain tain  the  controls  necessary  to  assure  delivery  of  each  Data  Itea  and 
prevent  unwarranted  duplication  of  Data. 

•5.1.6c  Governaent  Access  to  Mon-Deliverable  Data.  Provide  the 
Governaent  access  to  any  internal  Data,  formal  or  informal,  generated  under 
this  contract.  Such  internal  Data  includes,  but  is  not  limited  to,  aeaoranda, 
worksheets,  design  sketches,  or  computer-produced  listings  prepared  by  or  for 
contractor  or  subcontractor  personnel.  Prepare  and  deliver  aonthly  a Data 
Accession  List/Internal  Data,  which  identifies  all  such  internal  Data  by 
author,  source  organization,  title,  date,  and  identification  number.  Allow 
Governaent  personnel  to  examine  any  Data  Iteas  on  the  list  and  provide  up  to 
ten  copies  of  each  Data  Itea  specifically  requested.  Government  use  cf  such 
internal  Data  shall  be  limited  to  legitimate  purposes  of  CDS  developeent, 
training,  aodification,  and  maintenance. 

•5. 1.6.1  PBC  A 1071.  Technical  Publications.  Technical  publications 
comprise  all  Data  Itess  whose  CDRL  entries  specify  their  preparation  per  Data 
Item  Descriptions  (DIDs)  defined  in  category  M of  the  DoD  Authorized  Data 
pst.  Index  cf  Data  Itea  Descriptions  (TD-3).  This  contract's  technical 
publications  include  Positional  Handbooks,  Users  Manuals  Coaputer  Programing 
Manuals,  and  Catalog  and  Glossary  of  Coaputer  Programs  ant  Programing 
Documentation.  Propose  any  additional  computer- related  technical  publications 
deemed  requisite  and,  if  they  are  approved  by  the  Government,  incorporate 
their  identification  in  the  CPDP. 

5.1.b.2  PEC  A 1072.  Engineering  Data.  This  group  comprises  all  Data 
Items  whose  CDHL  entries  specify  their  preparation  per  DIDs  defined  in  TD-3 
categories  E,  H,  R,  S and  T. 

5.1 .6.2.1  PBC  A1072E.  Engineering  A Configuration  Documentation . All 
Data  Items  prepared  per  TD-3  category  E DIDs  comprise  this  category.  These 
include  the  CPDP,  specifications,  ECPs,  and  the  CPCIs  themselves. 
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5- 1-6. 2. 2 PBC  4107 2"  q Factors.  All  Date  Items  prepared  per  TD-3 

category  H DID*  comprise  this  category. 

5.1. 6.2.3  PBC  A1QT28.  Related  Peouiramcots.  All  D iU  I teas 

(e.g. , the  System  Security  Plan)  prepared  per  TD-3  category  R DIDs  comprise 
this  category. 

5. 1.6.2.*  PBC  A1Q72S.  Svstem/Subsvst*.  imlwla.  All  Data  Items, 

(e.g..  Technical  Reports,  Subsystem  Design  Analysis  Reports,  the  SEMP) 
prepared  per  TD-3  category  S DIDs  comprise  this  category. 

5- 1-6. 2. 5 PBC  A1072T.  lest.  All  Dels  Items  (e.g..  Test  Plans,  Test 
Procedures,  Test  Reports)  prepared  per  TD-3  category  T DIDs  comprise  this 
category. 

5. 1.6.3  PBC  A1QT3.  Management  Data.  All  Data  Items  prepared  per  TD-3 
category  A,  F,  L,  P or  ¥ DIDs  comprise  this  category. 

5.1. 6. 3.1  PBC  AKIRA,  Mmlnlmtrmtlw*  Management.  All  Data  Items  (e.g., 
the  Program  Milestones,  the  Data  Accession  List/Internal  Data)  prepared  per 
TD-3  category  A DIDs  comprise  this  category. 

5. 1.6. 3- 2  PBC  A1073F.  Financial.  All  Data  Items  (e.g..  Cost 
Performance  Reports)  prepared  per  TD-3  category  F DIDs  comprise  this  category. 

5-1. 6. 3-3  PBC  A1071L.  Logistic  Support.  All  Data  Items  (e.g., 
logistics  plans)  prepared  per  TD-3  category  L or  ¥ DIDs  comprise  this 
category. 

5. 1. 6. 3- *  PBC  Ax 07 IP.  Procurement/Production.  All  Data  Items  prepared 
per  TD-3  category  P DIDs  comprise  this  category. 

5-1.6.*  PBC  A107*.  Data  Repository.  Maintain  a master  engineering 
specification  and  drawirg  repository  service  for  Government-approved  documents 
that  belong  to  the  Government.  Maintain  each  document  at  the  latest  approved 
level  by  incorporating  approved  change  orders.  Similar  effort  required  for 
the  contractor's  internal  specif ication/drawing  control  system  is  excluded. 

5-1.7  PBC  11080.  Operational /Site  Activation 

Perform  the  tasks  prescribed  in  paragraphs  5. 1.7.1  - 5-1-7.*  and 
their  subparagraphs. 

5. 1.7.1  PBC  A 1081  . Contractor  Technical  Support.  Participate  in  a 
Government-conducted  site  survey  at  the  Rational  Command  Center  to  determine 
CDS  ."/ite  conversion  requirements . Provide  consultants  to  this  t e&a.  Staff 
the  Computer  Program  Development  Facility  (CPDF)  and  the  Computer  Program 
Maintenance  Facility  (CPMF)  per  the  CPDP.  (See  paragraph  5-1-7-*). 

5. K7-2  PBC  1108^.  Site  Conversion.  A Government-led  team  will  perform 
site  conversion  at  the  National  Command  Center,  to  include  preparation  of  the 
operational  site  and  the  CPMF. 
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•5.1. 7. 3 m iiflftit.. 


•5. 1.7.3. 1 PBC  1064*.  site  Checkout.  Assemble,  install, 

and  check  out  the  CDS  at  the  operational  site  prior  to  its  sys ten-level 
testing. 


5. 1.7. 3* 2 PBC  1084B.  CPDP  Checkout.  Check  out  the  CPDF  equipment  and 
software  per  the  CPDP  to  assure  their  proper  operation. 


•5* 1*7. 3> 3 PBC  1084C.  CPHF  Checkout.  Check  out  the  CPHF  equipment  and 
software  to  assure  their  proper  operation.  Perform  these  activities  per  the 
CPDP. 


5.1. 7. 4 PBC  *1085.  ADP  Support  Faculties. 

•5.1. 7. 4.1  PBC  1065k.  COnouter  Program  Development  facility  (CPDF). 
Provide  at  *he  contractor's  plant  an  equipnent  and  software  configuration,  and 
related  support  facilities,  for  the  developnent,  integration,  and  non-systen- 
level  DTAE  of  all  CDS  software,  per  the  CDS  Sts tew  Specification  and  the  CPDP. 

MOTE:  The  CDS  Sts  tew  Specification  is  presumed  to  define  the  CPDF  equipnent 

configuration  and  software  configuration.  The  CPDP  is  presuned  to  prescribe 
other  CPDF  requirements  (e.g.,  schedules,  support  organization}. 

•5.1. 7.*..2  PBC  .AiflfiSL..  -Qwptf ter  .P  norm 
Upon  completion  of  DT4E,  aove  the  CPDF  equipnent,  software  and  related 
facilities  to  the  National  Coantnd  Center,  where  it  shall  comprise  the  CPHF. 


MOTE:  See  the  Software  Acquisition  Management  Guide:  Software  Development  and 


Maintenance  Facilities  for  more  detail  on  requirements  and  tool  descriptions. 
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APPEMDIX  A 


BORE  BKEAKDOBI  STWCIURES 


Knowledge  of  Bork  Breakdown  Structures  (BBSs)  is  prerequisite  to  SOU 
preparation  because  UBS  and  SOB  structures  aust  at  least  partly  correspond 
(see  Section  2.1.1)  and  because  identical  codes  (see  Section  2.1.3)  aust 
identify  corresponding  SOB  paragraphs  and  the  Eleaents  of  certain  BBSs.  Bach 
BBS  Eieaent  represents  a well-defined  task  or  product,  or  a hierarchical 
aggregation  of  these,  to  be  developed  or  otherwise  acquired  during  the 
ays ten's  existence.  Soae  BBS  Eleaents  prescribe,  or  include,  the  developaent 
of  software. 

MIL-STb-88lA  prescribes  preparation  of  several  types  of  BBS  during 
planning  for  acquisition  of  Major  Defense  Systeas  and  aany  Less-Than-Major 
Systeas.  The  criteria  for  aandatory  application  of  KIL-STD-881A  include  an 
estlaated  Research,  Developaent,  Test,  and  Evaluation  cost  greater  than  $10 
aillion.  AFSCM  173-*,  Proa  tea  Breakdown  Structure  and  Cades,  suppleaents  MIL- 
STD-881A  for  pragmas  aanaged  by  AFSC  (e.g. , Electronic  Systeas),  if 
prescribed  by  the  PHD  or  by  AFSC  Fora  56- * AFSCM  173-*  requires  preparation 
of  Prog ran  Breakdown  Structures  (PBSs).  These  are  generally  consistent  with 
the  BBSs  prescribed  by  MXL-STD-881A,  but  are  soaewhat  no re  elaborate.**  This 
guidebook  applies  the  tera  BBS  generically  to  both,  except  where  it  aust 
distinguish  then. 

A1.  Bhat  BBSS  Are 

Basically,  a BBS  is  a hierarchical  (i.e.,  tree-structured) 
representation  of  the  tasks  and  the  products  (e.g.,  equipaent,  software,  data) 
that  coaprise  an  acquisition.  A BBS  depicts  the  chief  order  in  which  these 
tasks  and  products  will  be  aggregated  for  purposes  of  cost  accounting.  The 
single  highest-level  BBS  Eieaent  represents  the  overall  collection  of  tasks 
and  products;  e.g.,  a Coanand,  Control,  and  COaaunications  system  as  a whole. 
The  second-level  Eleaents  represent  the  whole's  aajor  parts.  The  depth  (i.e., 
nuaber  of  levels)  of  a particular  BBS  depends  on  its  type.  The  depth  of  a KBS 
also  depends  or  the  level  of  detail  at  tdiich  the  Governaent  wishes  to  aonitor 
and  control  developaent  effort.  In  soae  types  of  BBS  certain  branches  extend 
aore  deeply  than  others.  In  every  BBS  tre  Eleaents  at  the  saae  level  are 
disjoint  (i.e.,  they  represent  non-overlapping  groups  of  tasks  and  products). 
Table  A-1  illustrates  a three-level  BBS  of  even  depth.  Table  A-2  shows  a 
deeper  BBS  in  which  soae  of  the  branches  extend  to  fewer  levels  than  others. 


• AFSCM  173-*.  paragraph  1.3.  Paragraph  1.5  says  that  AFSCM  173-*  does  not 
apply  to  basic  research,  exploratory  developaent,  engineering  studies  or 
to  pragma  wide  management  support. 

••  AFSCM  173-*,  paragraph  2-2  explains  the  nain  structural  differences. 
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Table  *-i 


ELECTRONIC  STSTW  SUMMIT  HOK  5TI0CTUW 


1 Electronics  System 

2 Prise  Mission  Equipsent 

3 Integration  and  Assembly 

3 Sensors 

3 Co—unicationa 

3 Automatic  Data  Processing  Equipsent 

3 Cosputer  Progress 

3 Data  Displays 

3 Auxiliary  Equipsent 

2 Training 

3 Equipsent 

3 Services 

3 Facilities 

2 Peculiar  Support  Equipsent 

3 Organizational/Interaediate  ; Including  Equipsent  Common  to  Depot) 

3 Depot  (Only) 

2 Systess  Test  and  Evaluation 

3 Development  Test  and  Evaluation 

3 Operational  Test  and  Evaluation 

3 Hookups 

3 Test  and  Evaluation  Support 

3 Test  Facilities 

2 System/ Program  Management 

3 Systems  Engineering 

3 Project  Management 

2 Data 

3 Technical  Publications 

3 Engineering  Data 

3 fenagesent  Data 

3 Support  Data 

3 Data  Depository 

2 Operational /Site  Activation 

3 Contractor  Technical  Support 

3 Site  Construction 

3 Site/Ship/¥ehicle  Conversion 

3 System  Assembly,  Installation  A Checkout  on  Site 

2 Common  Support  Equipment 

3 Organizational /Intermediate  (Including  Equipsent  Common  to  Depot) 

3 Depot  (Only) 

2 Industrial  Facilities 

3 Construction/Conversion/Expansion 

3 Equipment  Acquisition  or  Modernization 

3 Maintenance 

2 Initial  Spares  and  Initial  Repair  Parts 

3  (Specify  bv  allowance  list,  grouping,  or  hardware  Element) 

• HIL-5TD-881A,  Appendix  B. 
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42.  W5  gw 


Prior  to  IFF  preparation,  BBSs  are  used  to  define  the  roles  and  primary 
products  of  an  acquisition's  Government  participants,  and  to  define  groups  of 
tasks  appropriate  for  contractors.*  Also,  costs  are  estimated  for  the 
Elements  of  certain  types  of  UBS  and  aggregated  as  a basis  for  planning  and 
program  approval.  Later,  actual  costs  are  accumulated  over  time  for  each 
Element,  this  information  is  sumaarixed  in  required  reports  to  higher 
headquarters.  The  program's  cost  history  by  Element  can  also  be  used  to 
Identify  problem  areas  needing  special  Program  Office  attention.  These  cost 
histories  can  also  help  to  develop  successive  projections  of  costs  to  complete 
the  acquisition  end  its  parts.  Ultimately,  such  cost  histories  can  be  used  to 
estimate  the  costs  of  similar  activities  and  products  on  other  programs, 
provided  the  corresponding  Element  definitions  are  comparable.  Thus, 
appropriate  definition  of  MBS  Elements  is  quite  important.  Application  of 
this  principle  to  software  is  especially  important  if  we  are  to  have  a sound 
quantitative  basis  for  estimating  the  costs  of  software  for  future  systems. 

Although  a MBS  depicts  the  principal  order  for  sunning  its  Elements' 
costs,  other  cost  breakdowns  and  orders  of  aggregation  are  often  desirable. 
Among  these  other  cost  accounting  categories  are: 

a.  System  configuration  grouping  (i.e.,  system.  Segment 
(if  any).  Functional  Area,  Cl,  equipment  component  or 
CPC,  and  possible  further  breakdowns); 

b.  Acquisition  Life  Cycle  phase  or  Computer  Program  Life  Cycle  phase; 

c.  Type  of  product  (e.g.,  operational  Executive,  application  program, 
compiler  (by  programming  language),  utilities);  and 

d.  Standard  accounting  categories  (e.g.,  direct  labor,  aaterials, 
computer  rental,  overhead (s) ) . 

Cost  information  in  several  other  categories  may  be  desired,  prescribed, 
collected,  and  summarized.  The  unambiguous  and  efficient  processing  of  such 
multidimensional  information  requires  definition  of  each  lowest-level  VBS 
Element  as  a cell  in  a n -dimensional  array,  where  each  dimension  corresponds 
to  an  order  of  aggregation.  Each  such  Element  must  also  be  assigned  a 
corresponding  key  by  which  the  data  collected  for  the  Element  may  be 
extracted,  sorted,  and  summarized.  This  need  can  be  satisfied  in  part  by 
appropriate  use  of  current  Program  Breakdown  Codes  (PBCs)  (see  Section  A3). 
However,  major  revision  of  the  PBCs,  now  under  study,  will  be  necessary  to 
encode  all  desired  categories.  In  addition,  other  information  usually 
collected  separately  free  cost  data  (e.g.,  CPC  size  and  execution  time  data) 
must  be  associated  with  the  right  Elements'  cost  data  if  meaningful 
comparisons  are  to  be  made. 


• AFSCH  173-*!  paragraph  4-2c.(2). 
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A3.  Element  Definition*  »nt} 


The  activities  or  products  that  comprise  each  Element  aust  be  well- 
defined.  The  definitions  of  the  Elements  at  the  first  three  levels  (termed 
Level  1,  Level  2 and  Level  3)  are  prescribed  in  HIL-.'5TD-88lA  appendices. 

AFSCH  173-4  extends  the  prescribed  levels,  and  defines  additional  El  meets. 

It  also  assigns  standard  PBCs  to  these  prescribed  Elements,  and  states  rules 
for  forming  PBCs  for  acquisition-specific  Eleneats.  The  PBCs  are  designed  to 
support  uniform  cost  accounting  across  systems.  Each  of  the  five  AFSCH  173-4 
attachments  identifies  a set  of  standard  Elements,  includes  their  official 
definitions,  and  presents  their  PBCs.  The  anticipated  revision  (i.e..  Change 
i)  of  ESDP  800-4,  Statement  of  Work  Preparation  Guide,  incorporates  additional 
standard  UBS  Elements  and  their  PBCs.  These  should  be  used,  where 
appropriate,  in  ESD-aanaged  programs.  Table  A-2  compiles  the  standard 
Electronic  System  UBS  Elements  from  these  three  sources  and  includes  the 
corresponding  PBCs. 

The  Program  Office  sust  identify  lover- level  Elements  (and  any  non- 
standard higher-level  Elements  desired),  prepare  these  Elements'  definitions, 
and  assign  then  PBCs  consistent  with  the  standard  Elements'  PBCs.  AFSCH  173— 
4,  Chapter  3,  explains  PBC  structure  and  requireaents  for  deriving  PBCs  for 
program-specific  lower-level  Elements.  Some  codes,  identified  as  "Restricted” 
in  the  AFSCH  173-4  attachments,  may  not  be  used  without  Hq.  AFSC  (ACC) 
approval,  per  ’.FSCH  173-4  paragraph  5-2. bOO).  For  ESP-managed  programs,  ESDP 
800-4  (Change  1)  supplements  these  rules. 

For  UBS  Elements  which  are  subsets  of  the  Prime  Mission  Product,  ESDP 
890-4  (Change  1)  defines  Extended  PBCs,  each  comprise  a main  portion  formed 
per  AFSCH  173-4  rules  plus  a suffix  that  indicates  the  Elenent's  position  in 
the  system  configuration.  This  suffix,  called  a Configuration  Identifier, 
specifies  the  position  of  each  software,  equipment  and  integration  Element  in 
the  Configuration  Tree  (e.g.,  the  Specification  Tree)  in  contrast  to  its 
position  in  the  UBS.  A Configuration  Identifier  consists  of  •/■  followed  by 
one  or  more  digits  or  letters.  The  first  of  these  specifies  the  Element's 
System  Segment  (if  any),  or  otherwise  the  systes  as  a whole.  The  second  (if 
any)  digit  or  letter  specifies  the  Functional  Area  (see  LCEG,  Section  4.3)  to 
which  the  Element  applies.  Any  third  digit  or  letter  indicates  which 
Configuration  Item  within  that  Functional  Area  to  which  the  Element  applies. 
Successive  digits  or  letters  should  be  used  for  any  Elements  that  apply  to  11 
components  ie.g.,  CPCs)  or  further  Cl  breakdowns.  The  digits  1-9,  and  then 
the  letters  A-H,  J-U,  and  P-Z,  should  be  used  as  successive  values  of  each 
Configuration  Identifier  position.  Table  A-2  and  Table  A-3  footnotes 
illustrate  Extended  PBC  formation.  Table  4 and  Exhibit  1 contain  several 
additional  examples  of  Extended  PBCs. 

Table  A-3  contains  Interim  Standard  PECs  for  identifying  the  type  and  the 
Computer  Program  Life  Cycle  phase  (see  LCEG,  Section  8)  of  each  Computer 
Programs  VBS  Element  subset  (i.e.,  each  CPCI,  CPC,  etc.).  The  Interim 
Standard  PBCs  nave  the  form:  s421xx[y],  where 

s is  a code  (i.e..  A,  B,  . . .)  that  identifies  the  software's 
supplier; 
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421  identifies  the  Element  as  a software  product; 

zz  is  an  alphanumeric  code  (tdiich  excludes  the  letters  *1"  ft  *0")  that 
designates  the  software  type;  and 

y when  used*  is  an  alphabetic  code  (i.e. , A-F)  that  identifies  the 

Computer  Prog  ran  Life  Cycle  phase  to  which  the  El  ones*  applies;  if  y 
is  not  used,  the  Element  is  presumed  to  enconpass  all  such  phases 
covered  by  toe  contract. 

Each  position  of  *xxa  nay  assune  24  alphabetic  values.  Also,  the  first 
*xxa  position  nay  assune  9 numeric  values  but  the  second  ”xx”  position  nay 
not,  per  AFSCM  173-4,  Chapter  3.  Thus,  this  code  can  represent  33  x 24  or  79 2 
different  software  types.  Since  Table  A- 3 defines  fewer  than  70  software 
types,  there  is  plenty  of  rooa  for  potential  expansion. 

The  Interin  Standard  PBCs  should  be  applied  to  all  costs  associated  with 
the  design  and  developaent  of  new  software,  and  to  the  purchase  or  rental  of 
connercial  software. 

In  addition,  contractors  should  be  required  to  break  down  and  report  the 
sane  costs  by  the  following  software  analogs  of  the  standard  MBS  Level  2 
categories  applied  to  the  entire  systen,  i.e.: 

£B£  Supplementary  Software  Category  jape 

4210  COaputer  programs  v analysis,  design,  coding,  checkout: 
purchase,  or  rental  costs  wily) 

4220  Software-peculiar  training 

4240  Equipment  required  specifically  for  software  developaent 
or  maintenance 

4250  Testing  of  software 

4260  Software-peculiar  management  and  engineering 

4270  Software  documentation 

4265  Software  development  and  maintenance  facilities 

4290  Other  software-rolated  costs 

4200  Summary  of  all  software-related  costs. 

Uherever  meaningful,  this  breakdown  should  extend  to  the  lowest  of  the  CPCI 
level,  the  Functional  Area  level,  or  the  System  Segment  level,  and  should  be 
encoded  by  suffixing  one-,  two-,  or  three-character  Configuration  Identifiers, 
respectively,  to  the  basic  PBC.  E.g.,  PBC  4250/2  would  enccde  Segment-level 
software  testing  costs  associated  with  the  system's  second  Segment. 
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til  merer  the  software?- related  activities  share  facilities,  supplies  or 
services  used  to  develop  o'J»er  portions  of  the  systea,  the  contractor  should 
be  directed  tc  apportion  their  costs  equitably  aaocq  the  systea 's  different 
product  categories  (e.g. , Communications , Coaputer  Programs,  Automatic  Data 
Processing  Equipment,  Sensors).  To  encourage  consistent  apportiooaent  across 
acquisition  prograas,  each  Prograa  Office  should  coordinate  proposed 
apportiocaent  rules  with  the  staff  organization  responsible  for  central 
collection  and  disseaination  of  cost  accounting  data.  For  ESP-managed 
prograas,  coordination  with  the  Cost  Analysis  Division  (ACC)  and  the  Coaputer 
Systems  Engineering  Directorate  (MCI)  is  required. 

The  Interim  Standard  Software  Types  and  PBCs  in  Table  A- 3 are  termed 
"inter la"  because  they  are  life  ly  to  change  as  software  cost  data,  and  related 
experience,  accumulate.  After  such  further  development,  their  standardization 
in  a future  revision  of  AFSCM  173-*  is  planned.  An  analogous  definition  of 
type  codes  for  Firmware  (PBC  *310)  is  currently  under  consideration. 

The  complete  set  of  Element  definitions  for  a particular  UBS  are  termed 
its  Dictionary. 

The  Intermediate  Command  Cost  Analysis  Division  (ACC)  sust  be  consulted 
about  all  proposed  new  and  modified  PBC  assignments.  Element  definitions,  and 
UBS  structures  (see  Section  2.2).  This  is  especially  important  because  the 
decisions  aade  about  these  matters  can  subtly  effect  cost  accounting , 
visibility  into  contractor  activities,  and  Government  control  of  these 
activities. 

A*.  UBS  Types  and  Evolution 

KIL-STD-6S1A  (paragraphs  *45)  identifies  seven  types  of  U3S  and 
prescribes  their  aevelopnent  sequence.  In  its  paragraph  5-2,  AFSCM  173-* 
defines  a PBS  analog  of  each  UBS  type  prescribed  by  MIL-STD-881A  and  mandates 
a very  similar  development  process  for  them.  The  chief  differences  between 
PBSs  and  HI L- STD-63 H UBSs  are: 

a.  some  differences  in  the  names  of  prescribed  Elements; 

b.  the  assignment  of  PBCs  to  PBS  Elements  (MIL-STD-381A  prescribes 
none ) ; 

c.  the  mandatory  inclusion  of  certain  prescribed  Level  * and  Level  5 
Elements  in  sooe  PBSs. 

Subsequent  subsections  describe  the  analogous  pairs  of  MIL- STD-881 A UBSs 
and  AFSCM  173-*  PBSs,  their  uses,  and  their  differences.  Both  members  of  a 
pair  are  discussed,  because  either  may  apply  to  a particular  acquisition, 
depending  on  the  program's  type,  size,  A importance,  and  on  specific 
direction.  Because  AFSCM  173— ^ identifies  some  of  the  same  types  of  PBS  by 
different  terms,  this  guidebook  uses  the  term  ti.  ut  seems  cost  standard. 
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Table  1.2 

ELECTBGKC  STSTBI  STAIDAJ©  MBS  ELEMENTS 


Uwl  PBC*  Source*  Source# 


1 

1000 

1,2,3 

1 

aMPsan?  —5 

Electronic  Syste*** 

2 

1010*# 

1,2,3 

3 

Prise  Mission  Product 

3 

1110 

1.2,3 

1 

Integration  and  isseabljr 

3 

2110 

1,2,3 

1 

S'nsors 

3 

3110 

1,2.3 

1,3 

Cossunicatious 

3 

4110 

1,2,3 

1 

Automatic  Data  Processing  Equipment 

3 

42100 

1,2,3 

1.3 

Computer  Progress 

3 

431000 

3 

3 

Fima  re 

3 

5110 

1,2,3 

1 

Data  Displays 

3 

6110 

1.2,3 

1 

Auxiliary  Equipment 

3 

8110 

2,3 

2 

lir  Vehicle 

2 

1020 

1,2,3 

1.3 

Training 

3 

1021 

1.2,3 

1,2,3 

Equips ent 

3 

1027 

1,2,3 

1,2,3 

Facilities 

3 

1029 

1,2,3 

1.3 

Services 

2 

1040 

1.2.3 

3 

Peculiar  Support  Equipaent  1 Maint- 

3 

1041 

1,2,3 

2.3 

enance  ( incl . Maintenance  Concept) 
Organize t ional / In teraed iate 

3 

1044 

1.2,3 

2,3 

Depot 

3 

1049 

2 

2 

Other 

2 

1050 

1.2,3 

1 

Systess  Test  and  Evaluation 

3 

1051 

1,2,3 

1,2,3 

Developaent  Test  1 Evaluation 

3 

1053 

1,2,3 

1,2 

Operational  Test  znd  Evaluation 

3 

1052 

3 

3 

CCsbined  DT1E  and  0T1E 

3 

1055 

1.2 

1 

Mockups 

3 

1056 

1.2.3 

1,2 

Test  and  Evaluation  Support 

3 

1057 

1,2.3 

1,2 

Test  Facilities 

3 

1059 

2 

2 

Other  Systes  Tests 

2 

1060 

1,2,3 

3 

Systea  Prograa/Project  Managesent 

3 

10611 

1.2,3 

3 

Systess  Engineering  Managesent 

1 

1C6U 

3 

3 

Reliability 

4 

1061B 

3 

3 

Maintainability 

4 

1061C 

3 

3 

Parts  Control 

4 

1Q61D 

3 

3 

Nosenclature 

4 

1061E 

3 

3 

Aerospace  Environsent 

4 

1061F 

3 

3 

Transportability 

4 

1061G 

3 

3 

Electrosagnetic  Cospat ibility 

4 

1061H 

3 

■j 

■u 

Radar  Frequency  Managesent 

4 

106 1J 

3 

3 

Security 

4 

10612 

3 

3 

Survivability 'Vulnerability 

4 

1061L 

3 

3 

Systes  Safety 

4 

106 1M 

3 

3 

Coasunications  Long  Lines 

4 

1061H 

3 

3 

Radio  Frequency  Managesent 

4 

1061P* 

3 

3 

Value  Engineering 

4 

106  IQ 

3 

3 

Availability 
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Table  A-2  (Continued) 


£&£• 

Sasasst 

Sourced 

Standard  Eleaent  kae 

1062 

1,2,3 

2,3 

Supporting  Project  Management 
Activities 

10621 

3 

3 

Prog  ran  Management 

106211 

3 

3 

Program/Contract  dork 
Breakdown  Structure 

10621B 

3 

3 

Cost  Information  System 

10621C 

3 

3 

Cost  Schedule  Systems 

106210 

3 

3 

Life  Cycle  Costs 

10621E 

3 

3 

Schedule  Management 

1062B 

3 

3 

Manufacturing  Management 

1062C 

3 

3 

Configuration  Management 

10620 

3 

3 

Integration  of  Analyses 
and  Related  Computer  Support 

1062E 

3 

3 

Qual ity/lnspection 

1062F 

3 

3 

Ptaotcg-aphic  Documentation 

1062G 

3 

3 

STINFO 

1063 

3 

3 

Integrated  Logistics  Support 

10631 

3 

3 

Preoperational  Supply  Support 

106 3» 

3 

3 

Packaging 

1063C 

3 

3 

Transportation 

10630 

3 

■> 

Travel 

106 3E 

3 

3 

Maintenance 

106 3G 

3 

3 

Limited  Spares/Repair  Parts 
Provisioning 

1061 

3 

3 

Crew/Human  Factors 

10611 

3 

■** 

0 

human  Engineering 

1061B 

3 

3 

Biomedical/Life  Support 
Equipment 

1061C 

3 

3 

Manpower/Personnel  Requirements 

1061D 

3 

3 

Human  Factors  Test  1 Evaluation 

1070 

1,2.3 

1,3 

Data 

1071 

1,2,3 

1,2 

Technical  Publications 

1072 

1.2,3 

1,2,3 

Engineering  Data 

1072E 

2 

2 

Bigineering  4 Configuration 
Documentation 

1072H 

2 

2 

Hiatan  Factor* 

I072B 

2 

2 

Related  Design  Requirements 

1072S 

2 

2 

System/Subsystem  Analysis 

1072T 

2 

2 

Test 

1073 

1,2,3 

1,2,3 

Management  Data 

10731 

2 

2 

Administrative  Management 

1073F 

2 

2 

Financial 

1073C 

2 

2 

Logistic  Support 

1C73P 

2 

2 

Procureoant/Productior. 

NONE 

1 

1 

Support  Data 

1071 

1.2,3 

3 

Data  Repository 

1080 

1,2,3 

1,3 

Operational/Site  Activation 

66 


Table  A-2  (Concluded) 


ament  Base 


lessl 

l 

•SQurqef 

Source# 

Standard  Element  1 mt 

3 

1081 

1,2,3 

1.2,3 

Contractor  Technical  Support 

3 

1082 

1,2,3 

1,2,3 

Site  Consti-uction 

3 

1083 

1,2,3 

2,3 

Site  Corversion 

3 

108  A 

1,2,3 

1,2,3 

System  Assembly,  Installation  and 
Checkout  cn  Site 

3 

108588 

3 

3 

ADP  Support  Facilities 

3 

1089 

2 

2 

Other  Site  Activation 

2 

9200 

1,3 

1,3 

Common  Support  Equipment 

3 

NOME 

1,3 

1 

Organizational /Intermediate 
(Including  Equipment  Common 
to  Depot) 

3 

NONE 

» 

i 

I>epot 

2 

NONE 

i 

1 

Industrial  Facilities 

3 

NONE 

1 

i 

Constructicn/Converrion/Expansion 

3 

NONE 

1 

i 

Equipment  Acquisition 
or  Modernization 

3 

NONE 

i 

1 

Maintenance 

2 

9600 

1,3 

3 

Initial  Spares  A Repair  Parts 

3 

NONE 

i 

1 

(Specify  by  Allowance  List, 
Grouping  or  Hardware  Element) 

• 

Prefix  this 

code  with  the 

letter  (i 

.e.,  A,B,...)  assigned  to  the  source 

of 

the  product  or  service 

when  tMs 

letter  is  known.  See  AFSCM  173-*, 

paragraph  3- 3a  and  Figures  5-3  through  5-8. 

# Source  Code:  1 = MIL- STD- 81 11,  Appendix  B. 

2 = AFSCM  173-*,  Attachment  A,  Section  C,  Part  1. 

3 = ESDP  800-*,  (Change  1),  Figure  2-1. 

••  Substitute  the  specific  system's  name  for  this  Standard  clement  name. 

##  For  ESD-aanaged  programs,  append  a Configuration  Identifier  to  the 
PBCs  for  equipment,  software,  and  integration  Elements  representing 
products  or  services  applied  to  distinct  System  Segments,  CIs,  Cl 
components,  etc.  * Configuration  Identifier  consists  of  "/*  followed 
by  one  or  core  digits  or  letters  that  specify  the  Element ’3  position 
in  the  System  Configuration.  A PBC  and  its  Configuration  Identifier 
form  an  Extended  PBC.  For  example,  the  Extended  PBC  "Bill  1/21*  would 
identify  integration  of  the  CIs  in  the  first  Functional  Area  of 
a system's  second  System  Segment. 

8 Apply  Table  A-3*s  Interim  Standard  PBCs  to  lower-level  Computer 
Programs  Elements. 

88  U3e  of  this  PBC  is  tentative  pending  revision  of  ESDP  8C3-<1. 

i See  last  two  entries  in  Table  1. 
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Table  A-3 


INTERIM  STANDARD  SOFTWARE  TYPES  AMD  PBCs« 


PBC** 

Type 
Index  # 

Tvoe  cf  Softwa**e 

*210 

_ 

Cooputer  Programs 

*219 

1. 

Operational  Software## 

*211 

1.1 

Application  Software## 

*212 

1.2 

Operational  Executive## 

4212A 

1.2. 1 

Cooputer  Resource  Management 

*212B 

1.2.2 

Computer  One rater  Interface 

*212C 

i.2.3 

Other  Terminal  Operator  interface 

*212D 

1.2.* 

Special  Device  Interface 

*212E 

1.2.5 

Other  Input  or  Ou  .put 

*212F 

1.2.6 

Error  Handling/Retonfiguration/Reeovery 

*2120 

1.2.7 

Multi-Computer  Conf  iguratior.  Control  Protocol 

*212H 

1.2.5 

Performance  Monitoring  A Data  Collection 

*213 

1.3 

Operational  Data  Base  Management## 

*213A 

1.3-  • 

On-Line  Data  Base  Retrieval  A Updating 

*21 3B 

1.3-2 

On-Line  Data  Base 

*21* 

» .« 

Operational  Exercise  or  Training 

*21*A 

1 .*.  1 

Control  of  Exercise  Seauencing 

*?1*B 

1 .*.2 

Operator  Performance  Data  Collection 

*215 

1.5 

On-Line  Equipment  Diagnostic 

*212 

2. 

Support  Software## 

*2U 

2.1 

Operating  System## 

*2 1AA 

2.1.  1 

Computer  Resource  Management 

*21A5 

2.1.2 

Computer  Operator  Interface 

*2 1AC 

2.1.3 

Otner  Terminal  Operator  Interface 

*21  AD 

2.1.* 

Other  Input  or  Output 

*2UL 

2.1.5 

Error-Bardling/Recor.figuration/Recovery 

*21Af 

2.1.6 

Pen'o.’mance  Monitoring  A Data  Collection 

*2  IB 

2.2 

Computer  Equipment  Maintenance## 

*213A 

2.2.  l 

Off-Line  Diagnostic 

*21C 

2-3 

Software  Development  A Maintenance## 

*21CA 

2-3- 1 

Higher-Order  Language  Compiler 

*2 1CB 

2.3.2 

Assemb.er 

*2  ICC 

2-3-3 

Debugging 

*2  1 Cl 

2 . jj  - * 

Loader  or  Editor 

*210 

2 . * 

Off-Line  Data  Base  Management## 

*2  IDA 

2.*.  1 

Data  Base  Definition 

*2  IDE 

2 . * . 2 

Data  Ease  Initialization  or  Updating 

*2  ICC 

2 . * . 3 

Data  Base  Retrieval  Output  Formatting 

*2  IT'D 

2 - * •' 

Data  Base  ? istructe  ung 

*2’DE 

2. *-5 

Cf f -Line  Data  Base 

*2  *E 

2-5 

System  Design  A Modification## 

Ac  1 JtA 

2-5.1 

System  Design  Data  Base 

*2,£b 

2.5-2 

System  Design  Data  Base  Processor 

*2  ’.EC 

: . . 5 . 3 

System  Performance  Simulation 

Performance  Tata  Redaction  1 Analysis 
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Table  A- 3 (Concluded) 


Type 


ffig? 

IffiteS  f 

Tree  of  Software 

*21F 

2.6 

System  Test  Software## 

*21FA 

2.6.1 

Test  Case  Generation 

*21FB 

2.6.2 

Test  Presentation,  Control  A Data  Recording 

*21FC 

2.6.3 

Test  Data  Reduction 

*21FD 

2.6.* 

Test  Analysis 

*21G 

2.7 

Utilities## 

*21GA 

2.7.1 

Media  Conversion  or  Format  Translation 

*2 1GB 

2.7.2 

Sort/Merge 

*21GC 

2-7-3 

Program  Library  Maintenance 

*21H 

2.8 

Adaptation  Software## 

*21  HA 

2.8.1 

Equipment  or  Software  Configuration  Data 

*21HB 

2.8.2 

System  Generation 

*21J 

2.9 

Off-line  Exercise  or  Training## 

*21 JA 

2.9.1 

Scenario  Preparation 

*21JB 

2.9.2 

Data  Reduction 

*21JC 

2-9-3 

Exercise/Training  Analysis 

*21K 

2.10 

Project  Management## 

*21KA 

2.10.1 

Project  Event  Status  Accounting 

*2 1KB 

2.10.2 

Schedule  Maintenance/Projection 

*21KC 

2.10-3 

Financial  Accounting 

• Apply  to  each  MBS  Element  the  PBC  tnat  best  defines  the  software  product 
(i.e.t  CPCI,  CPC,  or  major  routine)  to  be  acquired. 

••  Prefix  this  code  with  the  letter  (i.e..  A,  B,  C...)  assigned  to  the 

software's  supplier,  if  known  (see  AFSCM  173-*>  paragraph  3-3*  and  Figure 
5-3  through  5-8).  If  the  Element's  definition  limits  it  to  a particular 
Computer  Program  Life  Cycle  phase  (see  LCEG,  Section  8),  if  necessary  pad 
the  code  with  to  six  characters.  Then  suffix  it  with  a letter  (i.e., 
A-F)  tnat  represents  that  phase's  position  in  the  sequence  of  phases. 
Then,  to  form  an  Extended  PBC,  append  a Configuration  Identifier,  i.e., 
V"  plus  index  digits  or  letters  that  define  the  MBS  Element's  position 
in  the  system  configuration.  For  instance,  PBC  B*215*2/132  identifies 
the  Design  phase  of  an  On-Lir.e  Equipment  Diagnostic  Program  in  a system 
procured  from  the  acquisition  program's  second  source.  This  computer 
program  is  also  the  second  Cl  of  the  third  Functional  Area  of  the 
system's  first  Segment  (if  any)  or  otherwise  of  the  system  itself.  The 
Configuration  Identifier  must  contain  four  characters  to  designate  a CPC, 
and  five  to  designate  a major  CPC  part.  See  Table  4 for  other  examples. 

# Indicates  the  software  type's  position  in  this  type  classification  tree. 
Wot  directly  related  to  MBS  Le'-el. 

♦A  Code  as  this  type  of  software: 

1.  similar  software  not  otherwise  defined  by  a Table  A-3  PBC;  or 

2.  aggregates  of  other  components  of  this  type. 


69 


A*.  1 C> theory  Su—anr  MBSs  an^  anr  Kanaxene.1t  Structures 


MIL-STD-861 A defines  seven  MBSs  which  it  terms  Category  Suanary 
WBSs , for  Aircraft  Systems,  Electronic  Systsms,  Missile  Systems e Ordnance 
Systems,  Ship  Systems,  Space  Systems,  and  Surface  Vehicle  Systems, 
respectively.  Each  Category  Suaoary  MBS  consists  of  a complete  set  of  Level 
1,  Level  2,  and  Level  3 Elements  and  their  definitions,  appropriate  to  systems 
of  that  category.  Only  the  Electronic  System  Summary  MBS  includes  an  explicit 
software  Element  (i.e..  Computer  Programs).  Software- related  activities  and 
products  are  aggregated  with  other  types  of  activities  and  products  in  other 
Electronic  System  Summary  MBS  Elements,  and  in  Elements  of  the  other  six 
Category  Summary  MBSs.  Table  A-l  depicts  the  Electronic  System  Summary  MBS. 
The  single  Level  1 Element  always  represents  the  entire  system  being  acquired, 
including  equipment,  software,  and  data,  plus  effort  such  as  training,  testing 
and  systems  engineering  needed  to  develop  and  install  it.  Such  a whole  system 
might  be  a Major  Defense  System,  or  an  elaborate  software  system  procured 
separately  for  execution  on  computing  equipment  previously  acquired.  The 
Le*el  2 Elements  in  a Category  Summary  MSS  are  the  Prise  Mission  Product  plus 
the  major  categories  of  effort  or  auxiliary  products  normally  associated  with 
its  acquisition  and  support.  The  Level  3 Elements  are  standard  subdivisions 
of  the  Level  2 Elements. 

AFSCJi  l?3-«  (paragraph  5- 3a)  teres  Summary  Management  Structures  the 
PBS  equivalents  of  tne  Category  Summary  MBSs.  There  are  five  such  categories: 
Aircraft,  Electronics,  Ordnance,  Space,  and  Missiles.  These  are  equivalent  to 
five  of  the  seven  Ml L- STD-68 1 A categories.  Each  is  defined  in  Section  C,  Part 
1 of  ? separate  AF3CM  17  3-*  attachment . Unli«te  the  Category  Summary  MBSs,  the 
ArSCM  173-A  Summary  Management  Structures  define  a PBC  for  each  of  their 
Elements. 


Tne  Summary  Management  Structures  use  somewhat  different  names  than 
the  MIL-STD-861A  appendices  to  identify  equivalent  Elements  (e.g., 
"Communication  Equipment  - Total"  vs.  "Communications") , altnough  the  usually 
minor  differences  permit  matching  equivalent  Elements.  The  Summary  Management 
Structures  also  define  a few  level  * and  Level  5 Elements  (e.g.,  "Engineering 
and  Configuration  Documentation"  under  Level  3 "Sat a - Total").  More 
troublesome  are  omission  of  sene  Elements  defined  in  MIL-STD-881A  Category 
Summary  MBSs  (e.g.,  "Support  Data"),  and  inclusion  ?f  other  Elements  (e.g., 
"Other  System  Tests")  missing  from  Category  Summary  MBSs.  These  discrepancies 
will  presumably  be  rectified  in  the  next  version  of  AFSCH  173— ^ - fThe  current 
version  is  2"9  months  older  than  MIL- STD-86  - A ) . ESDP  SCO-*  (including  Change 
1)  contains  standard  MBS  Elements  that  partially  bridge  tne  gap.  Table  A-2, 
whicn  combines  the  Electronic  System  Summary  MBS,  The  Electronic  System 
Summary  Management  Structures,  and  tne  Standard  ESDP  5&0-*  MBS  Elements, 
indicates  their  similarities  and  differences. 

A* . 2 Preliminary  Project  Summary  MBS  anc  Preliminary  Summary  PBS 

XI L- STD-68 i A ^paragraph  directs  tne  Department  of  Defense 

(DoD)  Component  (e.g.,  the  Air  Force}  in  crarge  of  an  acquisition  to  prepare 
curing  the  Conceptual  Pnase  a Pre.imir.ary  Project  Summary  MBS  encompassing  all 
program  activities,  as  a oasis  for  program  approval.  A Preliminary  Project 
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Summary  VBS  is  compiled  by  selecting  fro*  one  or  sore  of  the  Category  Suaaary 
HliSs  the  subset  of  Elements  pertinent  to  the  planned  ays  tea.  Like  its 
sources,  the  result  is  normally  a three-level  structure.  However,  it  aay 
contain  Eleaents  at  or  below  Level  * if  based  on  appropriate  Systems 
Engineering  effort. 

A Preliminary  Sunaary  PBS  is  the  AFSCM  17 3- A equivalent  of  the 
Preliminary  Project  Sunaary  MBS,  (See,  e.g.,  AFSCM  173-A,  Figure  5-2).  AFSCM 
173-3  directs  its  coapilation  by  selecting  appropriate  Suaaary  Management 
Structure  Eleaents.  As  a result,  the  Preliminary  Suaaary  PBS  aay  contain 
Eleaents  below  Level  3.  For  ESD-aanaged  programs.  Table  A-2  aay  be  a 
convenient  source  of  such  Eleaents. 

The  Progra*  Office  Cadre,  if  formed , compiles  the  Preliminary 
Project  Sunaary  MBS  or  Preliminary  Suaaary  PBS.  Otherwise  the  Intermediate 
Command  planning  staff  does  so.  At  ESD,  coordination  with  the  Cost  Analysis 
Division  (ACC)  is  required.  AFSCM  173-A  directs  that  the  Prel  in  inary  Summary 
PBS  and  its  Dictionary  be  included  in  the  RFP  for  each  planned  post-Conceptual 
Phase  contract. 

At. 3 Approved  Project  MBS  and  Appro PBS 

Each  of  these  Smeary  MBSs  is  developed  from  its  preliminary 
counterpart  (see  Section  A3. 2)  as  a result  of  review  and  approval  actions. 

For  a Major  Defense  System  such  action  includes  Defense  Systems  Acquisition 
Review  Council  (DSARC)  consideration  and  the  Program  Decision  (see  LCEG 
Section  3. A).  The  approved  version  can  thus  be  expected  by  the  early 
Validation  Phase.  This  approved  version  must  be  included  in  all  RFPs  for 
Full-Scale  Development  Phase  contracts.  Per  KIL-STD-881A  (paragraph  A. 9),  the 
Elements  of  the  Approved  Project  Staaary  MBS  or  Approved  Sumsary  PBS  must  be 
defined  to  relate  easily  to  the  Contract  Line  Items  (see  Section  C2.1),  CIs, 
Government-Furnished  Property  (GFP),  Preliminary  Contract  MBS  Eleaents  (see 
Section  AA.A),  and  SOM  tasks,  or  aggregations  of  each. 

A3. A Preliainarv  Contract  MBS 

Both  MIL-STD-881A  and  AFSCM  173-A  use  the  same  term  for  this  type  cf 
MBS.  The  Program  Office  must  prepare  a different  Preliminary  CWBS  for  each 
planned  contract  (or  equivalent  Government  interagency  memorandum  of 
agreement)  from  the  appropriate  Project  Summary  MBS  or  Summary  PBS  version  by: 
(1)  selecting  a subset  of  the  source's  Elements,  and  (2)  subdividing  an 
appropriate  subset  of  these  into  Level  A,  Level  5,  and  possibly  lower-level 
Elements.  AFSCM  173-A,  in  Figures  5-3  through  5-7,  illustrates  the  process. 
All  branches  of  tne  Preliminary  Contract  MBS  need  not  have  the  same  depth. 

For  Validation  Phase  contracts,  the  Preliminary  Project  Suaaary  MBS  or  the 
Preliminary  Summary  PBS  must  normally  be  used  as  the  primary  basis  for  the 
Preliminary  Contract  MBS,  since  the  approved  version  is  unavailable.  For 
Full-Scale  Development  Phase  and  later  phase  contracts  the  Approved  Project 
Summary  MBS  or  the  Approved  Summary  PBS  will  be  used  instead.  The  appropriate 
Preliminary  CWBS  must  also  be  included  in  the  RFP  for  each  planned  contract. 
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For  ESD-managed  progress.  Table  A-2  should  be  reviewed  as  a source 
of  standard  lower-level  Elements  that  nay  be  appropriate  to  a Preliminary 
Contract  MBS.  In  addition  to  standard  Elements,  Elements  representing  system- 
specific  breakdowns  of  the  Prime  Mission  Product  and  its  Level  3 components 
(e.g..  Computer  Programs)  must  be  prepared.  For  example,  the  CIs,  if  already 
defined,  must  be  identified  as  Preliminary  CUBS  Elements.  For  a Validation 
Phase  contract,  the  CIs  will  not  normally  be  known.  However,  for  a Full-Scale 
Development  Phase  contract,  the  Cl  definition  should  be  available  as  part  of 
the  Allocated  Baseline  (see  LCEG,  Section  A. 3.1). 

In  addition.  Elements  covering  certain  Cl  subsets,  and  distinct 
Elements  for  each  of  the  integration,  training,  peculiar  support  equipment, 
test,  engineering,  management,  data,  etc.,  associated  explicitly  with  certain 
of  the  system's  product  Elements,  nay  be  desirable.  The  recent  Precision 
Emitter  Location  Strike  Systee  (PELSS)  procurement  (an  Aeronautical  System 
Division  product)  defined  such  distinct  support  Elements  at  several  levels  in 
its  Preliminary  CHBS- 

For  ESD-sanaged  prograss.  Table  A- 3 should  be  consulted  as  an  aid  to 
preparing  ?'SCs  for  Elements  defining  software  products  (e.g.,  CPCIs  or  their 
subsets).  To  obtain  unambiguous  software  development  cost  data,  a separate 
Element  should  be  defined  for  each  Coeputer  Program  Life  Cycle  phase  (see  LCEG 
Section  8)  of  each  software  product  to  be  developed.  This  breakdown  may  be 
included  in  the  Preliminary  CWBS  or  the  winning  Offeror  may  be  required  to 
extend  the  CWBS  accordingly  (see  Section  A*. 6). 

Properly  defining  a Pre* iminary  CWBS  fer  each  planned  contract  is  a 
crucial  acquisition  planning  activity,  and  an  essential  prerequisite  to  SOU 
preparation.  The  Preliminary  CWBS  is  very  much  influenced  by  the  system 
design,  and  by  concepts  of  system  acquisition  management,  operation,  training, 
and  maintenance.  Because  of  their  close  relationship,  the  Preliminary  CUBS 
may  change  during  SOW  preparation. 

A*. 5 Contract  WBS  (CUBS) 

The  CWBS  for  each  contract  is  developed  from  the  corresponding 
Preliminary  CWBS  by  Government  negotiation  with  the  winning  Offerer.  Per  MIL- 
5Tl>-86lA  (paragraph  5-3-2),  any  contractor-proposed  changes  require  the 
Program  Manager's  approval,  and  must  be  consistent  with  the  Approved  Project 
Summary  MBS  or  Approved  Summary  PBS.  The  CWBS  becomes  part  of  the  contract. 
The  negotiated  CWBS  Elements  should  correspond  to,  rather  than  cross,  the 
contractor's  existing  management  and  cost  accounting  categories,  if  the 
Government  deems  these  categories  adequate.  To  use  a management  and  cost 
accounting  structure  familiar  to  the  contractor  is  less  expensive  than 
imposing  a new  one,  and  will  probably  yield  more  accurate  data. 

A4.6  Extended  CWBS 

Each  contractor  may  extend  his  CWBS  by  further  defining  Elements  at 
lower  levels  to  serve  his  own  management  objectives.  However,  his  costs  »ust 
be  traceable  by  the  Government  to  the  lowest  level  Elements  he  defines.  He 
need  not  report  costs  routinely  at  tn;s  level,  unless  his  contract  so  directs, 
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but  aust  be  able  to  asseable  the  information  at  Program  Office  request. 
However,  this  reporting  is  aost  likely  to  be  realistic  if  routine,  and  if  the 
Extended  CUBS  categories  reflect  both  the  contractor's  internal  accounting 
systea  and  (ubere  appropriate)  the  actual  structure  of  the  Cls  under 
developaent. 

To  collect  sound  so  ft  were  cost  data  as  a basis  for  future  software 
cost  estiaates  (see  Section  12) , software  developaent  cost  data  should  be 
accianilated  separately  for  each  CPCI  to  be  developed  under  the  contract,  and 
for  their  Ccaputer  Program  Coaponents  (CPCs).  This  data  should  be  further 
segregated  by  Computer  Prograa  Life  Cycle  phase  (see  LCEG,  Section  8).  To 
assure  routine  Goveraaent  acquisition  of  this  information,  a SOU  task  should 
direct  the  contractor  to  extend  the  CUBS  accordingly,  and  to  report  the 
corresponding  software  developaent  costs  in  aonthly  Cost  Performance  leports, 
separately  for  each  such  Extended  CUBS  Element. 

£ similar  need  exists  for  software  size  and  timing  data,  as  a basis 
for  estimating  the  performance  of  future  software.  Bence,  a SOU  task  should 
require  size  and  execution  time  data  for  each  CPCI  and  CPC  defined  in  the 
Extended  CUBS.  (See  Exhibit  1,  paragraphs  5- 1-5- 1-B  and  5. 1.5. 2. 1.1). 
Ultimately,  experience  may  show  that  this  data  aust  be  collected  for  portions 
of  CPCs  (i.e.,  individual  routines)  if  such  data  is  to  be  comparable. 

11.7  Project  UBS  and  Extended  PBS 

The  Program  Office  is  responsible  for  developing  these  by 
aggregating  all  Extended  CUBS  Elements  with  the  Approved  Project  Suaaary  UBS 
Elements  or  approved  Summary  PBS  Elements  that  represent  work  from  all  the 
developaent  organizations.  HI L- STB- 881 A (paragraph  5.1)  directs  developaent 
of  this  UBS  (which  when  complete  fully  depicts  the  entire  acquisition).  This 
developaent  aust  begin  when  the  first  contract  is  awarded,  continue  as 
subsequent  contracts  are  awarded  (and  as  the  program  changes),  and  be  complete 
by  the  end  of  Full-Scale  Development. 
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APPEKJIX  B 


THE  SOURCE  SELECTIO*  PLAR 


AFB  70-15,  Source  Selection  Policy  and  Procedures  (paragraph  2-2) 
prescribes  preparation  and  approval  of  a Source  Selection  Plan  (SSP)  as  a 
prerequisite  to  RFT  completion  and  release.  Paragraph  2-2  further  defines  SSP 
content,  and  responsibilities  for  its  development.  The  SSP  aust  contain  the 
approach  and  Government  organization,  plus  the  criteria  and  schedule  for 
proposal  evaluation  and  contractor  selection. 

Per  APR  70-15  (paragraph  1-3v) , the  SSP  aust  be  approved  by  the  Source 
Selection  Authority  (SSA).  For  Air  Force-aanaged  Major  Defense  Systems,  AFR 
70-15  (paragraph  1-5)  prescribes  the  Secretary  of  the  Air  Force  as  the  SSA, 
unless  the  Secretary  of  Defense  directs  otherwise.  The  Secretary  of  the  Air 
Force  aay  delegate  this  authority,  but  not  below  the  level  of  an  AFSC  Division 
Commander  (e.g..  Commander,  ESD). 

A lower- ranking  person  may  be  appointed  as  the  SSA  for  a Less-Th  an -Major 
System  proposal  evaluation.  AFR  70-15  (in  paragraphs  1-3w,  l-3y  and  l-7b) 
also  prescribes  formation  of  a Source  Selection  Advisory  Council  (SSAC).  The 
SSAC  aust  partially  develop  proposal  evaluation  criteria*,  appoint  a Source 
Selection  Evaluation  Board  (SSEB),  analyze  the  results  of  each  proposal's 
evaluation,  and  otherwise  advise  the  SSA.  Detailing  of  proposal  evaluation 
criteria  and  proposal  evaluation  itself  are  the  SSEB's  prime  responsibilities. 

SSP  preparation  is  a Program  Office  Cadre  responsibility,  with  help  from 
prospective  SSZB  members  who  are  not  Program  Office  personnel.  Because  its 
approval  aay  require  considerable  time,  the  SSP  for  contract(s)  to  begin 
during  the  Validation  Phase  should  be  submitted  for  approval  during  the 
Conceptual  Phase  (see  LCEG,  Table  1,  Set  U) . When  contractile  is  planned  to 
start  no  earlier  than  Full-Scale  Development,  the  SSP  should  be  submitted  as 
early  as  possible  in  the  Validation  Phase. 

Per  IFF  70-15  ( paragraph  2-2),  the  SSP  aust  normally  include  at  least  the 
followite: 

a.  an  introduction  outlining  the  system,  and  the  group  of  supplies  and 
services  to  be  procured  under  each  planned  contract; 

b.  screening  criteria  to  eliminate  unqualified  Offerers  before  proposal 
evaluation,  while  assuring  adequate  ccspetition; 


• See  AFR  70-15,  paragraphs  3-2  through  3-5,  and  ESD-TR-75-365,  paragraph 
3.3,  for  guidance  about  proposal  evaluation  criteria,  including  standards 
and  examples . 

NccAg  pp  Umk 
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c.  Basic  Evaluation  Criteria  (subject  to  further  SSAC  detailing), 
tailored  to  vital  aspects  of  each  procurement,  and  specifically 
addressing  high  risks  and  technical  uncertainties;  the  relative 
importance  cf  each  Basic  Evaluation  Criterion  nust  also  be  stated; 

d.  the  Source  Selection  organization  (e.g.;  SSA;  SSAC;  SSEB; 
reccnm  ended  aeabers  by  organization,  and  by  name  where  possible); 

e.  evaluation  procedures,  including  the  SSEB's  rating  aethods  and  the 
SSAC's  proposal  evaluation  approach; 

f.  plans  for  evaluating  costs,  including  identification  of  the 
Preliminary  CUBS  items  Whose  costs  nil a be  evaluated,  plus  methods 
to  be  used  for  independent  Government  cc^t  estimation. 

g.  a schedule  of  Source  Selection  activities;*  and 

h.  the  procurement  approacc,  directly  correlated  with  the  Procurement 
Plan;**  this  must  cover  planned  type(s)  of  contract,  incentives,  and 
special  clauses. 

Per  AFH  70-15  (paragraph  2-2),  the  SSP  nust  also  comply  with  any  PHD 
direction  regarding  Source  Selection. 


• AFR  70-15,  Attachment  1 lists  32  events  to  be  included  in  this  schedule. 
Paragraph  1-15  allows  at  sost  18  weeks  to  complete  Source  Selection, 
beginning  with  receipt  of  the  Offerer's  fornal  proposals,  unless  the  SSA 
authorizes  core  time. 

••  Air  Force  ASPR  Supplement  1-2100.50,  and  ESD-TR-75-365,  paragraph  2.3-3- 
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APPESEIX  C 


REQUESTS  FOR  PROPOSAL 


A Bequest  for  Proposal  (RFP)  is  a formal  doc went  used  by  the  Air  Force 
to  solicit  proposals  from  a Source  List  of  potential  contractors.  If  there 
are  to  be  two  or  more  contracts,  a separate  RF?  and  a separate  Source 
Selection  (see  Appendix  B)  are  required  for  each,  unless  parallel  competitive 
contracts  are  awarded  to  perform  the  same  tasks.  Each  RFP  describes  a group 
of  supplies  and  services  wanted,  states  conditions  for  their  acquisition,  and 
solicits  proposals  accordingly. 

AFR  70-15,  which  explains  the  Major  Defense  System  Source  Selection 
process  for  both  Validation  Phase  and  Full-Scale  Development  Phase  contracts, 
should  be  reviewed  before  RFP  preparation.  This  directive  imposes  certain 
requirements  on  RFP  structure  and  content,*  and  explains  bow  the  responses  to 
an  RFP  (i.e.,  the  Offerers'  proposals)  should  be  evaluated.  The  policies  and 
procedures  of  AFR  70-15  may  also  be  tailored  for  use  in  Less-Than-Najor  System 
acquisition  programs,  or  AFSCR  70-9,  Source  Selection  Procedures . and  AFSCR 
80-15  BAD  Source  Selection  Policy  and  Guidance,  may  be  applied. 

RFP  preparation  is  a joint  responsibility  of  the  Procuring  Contracting 
Officer  and  the  Program  Office,  but  requires  SSAC,  and  SSEB  participation  and 
concurrence.**  Program  Office  personnel,  including  the  Software  Director,  are 
responsible  for  drafting  and  reviewing  the  major  portions  of  each  RFP.  For 
ESP-managed  programs,  review  by  the  Computer  Systems  Engineering  Directorate 
(MCI)  is  also  required. 

A RFP  for  a software-related  Validation  Phase  or  Full-Scale  Development 
Phase  contract  consists  of  three  voljmes,  plus  a possible  fourth  volume 
containing  any  classified  information.  In  addition,  a brief  Executive  Summary 
letter  is  sent  to  each  Offerer  with  the  RFP.  This,  signed  by  the  Program 
Manager,  should  highlight  the  RFP's  major  points  in  2-3  pages.  The  principal 
components  of  am  RFP  are  described  below. 

ASPR  3-501  describes  a Uniform  Contract  Format  (UCF)  to  be  used  in 
negotiated  Procurements  (see  Section  1).  RFP  structure  must  correspond 
closely  to  the  UCF,  as  indicated  in  Table  C-l#,  to  facilitate  negotiating 
contracts  that  differ  little  from  evaluated  proposals.  There  are  four  RFP 
Volumes,  sometimes  called  Parts.##  Bach  is  discussed  below.  AFSCP  70-*,  the 
standard  forms  mentioned  below,  and  the  other  references  cited,  should  be 
consulted  for  further  details. 


* AFR  70-15,  paragraph  2-*,  has  examples. 

••  AFR  70-15,  paragraphs  l-7b,  l-7d  and  2-*a. 

# Table  C-l  is  adapted  froo  AFSCP  70-A,  Figures  2-1  and  2-2. 

##  AFSCP  70-A  uses  the  t era  Volume,  while  standard  RFP  iorms  (e.g..  Form  33) 
use  the  term  Part. 


77 


Table  C-l 

UNIFORM  CONTRACT  FORMAT  va.  R»  P FORMAT 


(Preliminary  or  App-nvad  Varalon) 
Preliminary  Contract  WBS 


ci.  IF?  Toluae  T = Proposal  Preparation  Instructions 


Volume  I is  soaetlaes  termed  the  Instructions  for  Offerers  or  the 
Instructions  for  Proposal  Preparation  ( IFPP) . It  consists  of  the  four  sain 
parts  described  in  Sections  C1.1  - Cl. I. 

Cl. 1 Cover  Sheet  (DP  Fora  1707) 

This  contains  information  such  as  the  name  and  identification  nuaber 
assigned  to  the  potential  contract,  the  issuing  Government  office,  and  the 
Government's  official  point  of  contact  with  Offerors. 

Cl. 2 Contract  Forms  and  BepresenUtions,  etc. 

This  consists  principally  of  the  Solicitation,  Offer  and  Award 
(Standard  Fora  33)  plus  possible  supplementary  material.  It  identifies  all 
parts  of  the  RFP,  specifies  terns  for  delivery  of  the  proposal,  and  contains  a 
nuaber  of  questions  pertinent  to  the  proposed  contract  to  be  answered  by  each 
Offerer. 

Cl. 3 Solicitation  Instructions  and  Conditions 

This,  comprising  Standard  Fora  33A  plus  supplementary  material,  must 
guide  the  Offerers  on: 

a.  type  of  proposal  expected; 

b.  definition  of  information  to  be  included; 

c.  proposal  format,  including  packaging  by  volumes  and 
sections;* 

d.  ways  Offerers  can  get  questions  answered; 

e.  mechanics  of  proposal  sutaission,  revision  and  evaluation; 

f.  the  bases  for  contract  award; 

g.  grounds  for  rejecting  a proposal  as  unacceptable; 

h.  order  of  information  precedence  if  HFP  portions  conflict; 

i.  instructions  for  CDRL  preparation  (see  Section  C2.7); 

j.  security; 


AFSCP  70-5,  paragraph  3-6,  has  extensive  specific  suggestions. 
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k.  type  of  contract  planned;* 

l.  ISPS  sections  incorporated  by  reference; 

s.  number  of  proposal  copies;  and 

n.  any  proposal  size  limitations. 

For  ezasple,  the  IFF?  should  spell  out  clearly  and  precisely  how 
each  Offerer  is  expected  to  state  and  format  his  technical  proposal,  primarily 
to  assure  receipt  of  comparable  proposals  from  the  different  Offerers.  Each 
Offerer's  pertinent  qualifications  and  experience,  his  management  structure,, 
and  his  cost  l pricing  data  should  be  requested  in  comparable  terms.  The  IFPP 
may  also  impose  a proposal  page  nueber  limit  to  constrain  the  costs  of 
proposal  preparation  and  the  effort  of  proposal  evaluation. 

for  a contract  involving  ncn-trivial  software  development,  the  IFPP 
should  require  delivery  of  a CPDP,  prescribe  its  content  and  format,**  and 
state  that  the  winning  Offerer's  CPDP  (after  possible  change  during 
negotiation)  bind  the  contractor.  This  IFPP  provision  will  let  the 

government  evaluate  the  CPDP  during  Source  Selection,  as  a principal  indicator 
of  the  Offerer's  competence  to  develop  the  software  contracted  for.  The  same 
provision  in  the  contract  will  permit  Government  enforcement  of  the  winning 
Offerer's  CPDP  during  software  development. 

For  a contract  that  includes  Systems  Engineering  effort,  the  IFPP 
should  also  require  each  Offerer  to  prepare  a SEMP,  to  become  binding  on  the 
winner,  as  outlined  in  LCEG,  Section  4.4.6. 

If  tne  acquisition  plan  allows  Offerers  to  propose  changes  to  the 
validated  system  design  (see  LCEC,  Section  4.3.2),  the  IFPP  should  spell  out 
tne  types  of  possible  codifications  allowed,  the  evidence  necessary  to  support 
thea,  and  the  standards  to  be  applied  to  their  evaluation. 

Cl. 4 Evaluation  Criteria 

Per  AFR  7C-15  (paragraph  l-7b),  preparation  of  General  Evaluation 
Criteria  is  a SSAC  responsibility,  but  Program  Office  personnel  usually 
prepare  the  drafts.  This  RF?  section  should  state  in  general  terms  the 
criteria  the  Government  plans  to  use  to  evaluate  the  proposals,  and  the 
relative  importance  of  each  aspect  of  the  proposal  (e.g.,  price,  technical 


• E.g.;  Firm  Fixed  Price  (FFP);  Fixed  price  Incentive  Fire  (FPIF);  Cost 

Plus  Fixed  Fee  (CFFF);  Cost  Plus  Incentive  Fee  (CPIF);  Cost  Plus  Award 
Fee  (CPA?; . 

••  AFR  3G0-14,  Vol.  II,  paragraph  3-9  and  Data  Item  Description  (DID,  (U) 
DI-E-695/ESD,  Computer  Program  Development  Plan,  define  the  CPDP. 
However,  the  RFP  should  contain  a modified  version  of  this  DID,  t>  cover 
application-specific  requirements , and  to  eliminate  requirements  for 
information  to  be  provided  elsewhere  in  tne  proposal.  DID  modification 
is  discussed  in  ESD-TP.-76- 1 39 • 
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■erit).  The  HFP  should  identify  any  n on-obvious  technical  risks.  Offerers 
should  also  be  asked  to  identify  factors  in  their  proposals  that  are  critical 
to  acquisition  or  system  success.  The  General  Evaluation  Criteria  should 
include  consideration  of  such  critical  factors  and  of  high-risk  proposal 
provisions . 

Currently,  the  following  softuare  capabilities  are  likely  to  have 
high  technical  risk: 

a.  certifiably  correct  control  of  access  to  data  of 
different  security  classification  and  in  different 
•need  to  know"  categories; 

b.  automatic  detection  and  correct  reporting  of  equipment 
and  software  errors;  and 

c.  automatic  reconfiguration  and  recover;  of  the  systea  froa 
errors,  including  transition  to  and  froa  degraded  nodes 
of  operation. 

The  HFP  should  ask  Offerers  to  address  the  technical  risks  concerning  each  of 
these  items,  if  included  in  the  systea  design  requited  or  proposed. 

The  risks  of  cost  and  schedule  overruns  typically  overshadow 
technical  risks  in  software  development.  Therefore,  the  RFP  should  require 
Offerers  to  address  cost  and  schedule  risks  in  their  proposals,  with  reference 
to  their  proposed  CPDPs  (see  Section  Cl. 3). 

The  RFP  must  also  state  the  importance  to  evaluation  of  factors 
extraneous  to  the  proposal  icsalf,  which  AFR  70-15  (paragraphs  3-2d  A 2-«e) 
terms  General  Consideratters.  These  factors  include  the  Offeror's  past 
performance. 

Neither  the  Detailed  Evaluation  Criteria  to  be  applied  by  the  SSEB, 
nor  the  exact  weights  to  be  attached  to  each  criterion  by  the  SSAC,  should  be 
revealed  to  Offerers.  Nevertheless,  the  RFP's  General  Evaluation  Criteria 
should  be  as  informative  as  possible,  in  order  to  elicit  the  best  possible 
proposals,  to  ainiaize  aisunderstandings , and  to  avoid  claias  by  losing 
Offerers  that  their  proposals  were  treated  unfairly.  Refer  to  AFR  70-15, 
paragraphs  2-ba,  3-3,  and  Attachment  2,  for  further  diriction. 

Preparation  of  a good  set  of  General  Evaluation  Criteria  for  the  RFP 
should  be  based  on  carefully  considered  Detailed  Evaluation  Criteria.  Thus, 
the  latter  should  normally  be  developed  before  the  HFP  is  released,  and  aust 
be  compiled  before  receipt  of  contractor  proposals,  per  AFR  70-15,  Attachment 
1.  For  this  reason,  Basic  Evaluation  Criteria  must  be  included  in  the  SSP 
(see  Appendix  3)  which  aust  be  approved  by  the  SSA  before  the  RFP  is  issued. 
The  RFP  General  Evaluation  Criteria,  and  their  relative  importance,  sust  be 
consistent  with  the  Basic  Evaluation  Criteria  approved  by  the  SSA. 
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C2.  1FP  lolme  II  - Model  Contract 


The  Model  Contract  comprises  a description  of  the  supplies  and  services 
to  be  provided  by  the  contractor,  the  Delivery  Schedule,  the  Contract  Tents 
and  Conditions,  Contract  Administration  Data,  and  the  CDRl.  Basically,  the 
Model  Contract  is  the  Government 's  initial  contract  proposal.  It  is  subject 
to  change  during  the  negotiations  that  are  later  conducted  with  each 
qualifying  Offerer. 

ArR  70-15  (paragraph  1-4h)  sandates  inclusion  c*  a Model  Contract  in  a 
Validation  Phase  or  Full-Scale  Development  Phase  SFP.  Such  inclusion  is 
intended  to  de^  le  clearly  to  Offerers  what  the  Government  desires,  and  to 
limit  negotiation  to  possible  alteration  of  specific  Model  Contract 
Provisions.  Use  of  a tailored  Model  Contract  can  also  assure  appropriate  and 
consistent  contractual  provisions  governing  issues  common  to  many  acquisition 
prograns.  Subsequent  subsections  discuss  those  Model  Contract  sections  most 
relevant  to  software- '•el  a ted  SCW  preparation.  In  addition  k review  of  ASPR  3- 
501,  and  of  an  actual  contract  for  a Major  Defense  System  or  a Segment  of  one, 
is  recommended  prior  to  SOW  preparation. 

C2. 1 Supplies  and  Services 

Tnis,  Model  Contract  Section  E,  lists  the  major  groups  of  supplies 
and  services  to  be  provided.  Each  such  group  is  termed  a Contract  Line  Item 
and  is  represented  by  a unique  name  and  serial  number  (e.g.,  0001,  0002). 

Some  Contract  Line  Items  are  broken  down  into  major  parts  called  Subline 
Items.  Each  Subline  Item  must  have  a unique  name,  and  a serial  number  (e.g., 
0002AA,  0G02A5)  formed  by  appending  an  alphabetic  suffix  to  its  Contract  Line 
Item's  serial  number.  Section  L includes  a quantity,  and  depending  on  the 
type  of  contract  planned  may  include  a price,  for  each  Subline  Item,  and  for 
each  Contract  Line  Item  that  has  no  Subline  Items.  Hereafter,  Subline  Items, 
and  Contract  Line  Items  without  Subline  Items,  are  both  termed  CLIfe.  The 
prices,  and  tne  overall  contract  targets,  ceiling,  or  costs  and  fee  agreed  on, 
become  part  cf  tne  negotiated  contract's  Section  E.  To  avoid  potential 
contract  enforcement  problems,  each  CLIN  must  be  described  by  a specific  SOW 
paragraph  and  Preliminary  CW5S  Element  of  tne  same  name.  Usually,  CLIJis  cover 
relatively  high-ie/ei  aggregation  cf  supplies  and  services.  When  this  is  so, 
CLIJis  will  correspond  to  SOW  paragraphs  that  encompass  lower-level  SOW 
paragraphs. 

Appropriate  definition  of  CLI.is  depends  on  several  other 
considerations,  including  the  following.  Supplies  and  services  to  be 
delivered  at  different  times  to  different  places,  or  to  which  different 
acceptance  criteria  apply,  should  normally  be  identified  as  different  CLIMs. 

To  support  maximum  Government  influence  on  software  development,  every  CPCI 
should  oe  identified  as  a distinct  CLIN . Every  CPCI  should  also  be 
represented  oy  an  Exhibit  CLIN;  i.e.,  a CLIN  which  identifies  a CDRL  Entry 
(see  Section  C2.1.2).  In  aggregate,  the  Exhibit  CLIXs  must  rcierence  all  CDhL 
entries. 


C2.1.1  CPCI  Version  Definition.  Release  of  mere  than  one  Version  of 
certain  CPC  1 2 -r.de  r development  is  often  desirable.  For  example,  ea  ly 
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delivery  of  an  austere  Version  of  an  Operational  Executive  CPC I say  be 
essential  to  tisely  and  realistic  testing  of  concurrently  developed 
Application  CPCIs.  Each  such  Version  must  be  documented,  and  subjected  tc 
acceptance  testing,  adequate  to  its  intended  uses.  Because  software  is  easily 
tut  r.ct  always  correctly  changed,  and  because  such  changes  are  hard  to  detect, 
each  Version's  storage  nedia  and  documentation  suit  also  be  clearly  and 
consistently  laoelled. 

Per  HIL-STD-*83(USAF)  (paragraphs  80. 10-80. 12)  each  Version  of  a CPC1 
sust  be  defined  in  a Version  Description  Docusent  (VDD) . A VDD  includes 
unique  Version  identification,  storage  nedia  identification.  Functions 
incorporated  (cross-referenced  tc  specifications  and  listings),  site 
adaptation  paraneters  (if  any),  interfacing  equipoer.t  and  software  (and  how 
affected),  operational  impact . installation  procedures,  and  known  and  possible 
errors.  A precise  Version  description  alsv  requires  correct  listings  of  the 
Version's  coding,  and  say  require  other  docueentation.  ?.efer  to  DI-E-3121, 
Version  Description  Document  (Coaputer  Progrera)  for  further  information  about 
VDIs. 

If  they  can  be  well-defined  before  or  during  contract  negotiation,  the 
Incremental  Versions  of  CPCIs  say  be  identified  as  separate  CLINs.  However, 
correct  early  Version  definition  is  improbable,  and  would  entail  explicit 
contract  modification  if  a Version  or  its  delivery  requirements  later  changed. 
Also,  separate  CLINs  imply  separate  WBS  Elements,  CIs,  and  CDRL  entries. 

Thus , defining  incremental  Versions  as  CLINs  is  not  recoasxended . 

Greater  flexibility  can  be  achieved  if  the  Supplies  and  Services  section 
of  tne  contract  instead  defines  a single  CLIN  Tor  all  Versions  of  each  CPCI. 

In  addition,  the  contract's  Descripticn/Specifications  (see  Section  C2.2? 
snould  identify  each  Version.  The  contract's  Delivery  Schedule  (see  Section 
C2-3J  should  state  when  each  is  dellve-able . The  contract's  Inspection  and' 
Acceptance  provisions  (see  Section  C2.S)  should  specify  the  terms  or  these 
Versions'  delivery.  Related  SOW  paragraohs  oust  call  for  their  Versions' 
preparation.  Finally,  the  CDRL  xust  define  both  the  documentation  required 
and  the  software  storage  aedia.  Clearly,  these  separate  RFP  provisions  should 
be  coordinated  for  completeness  and  tcr.sistency. 

C2.1.2  Dual  Identification  of  Software.  Besides  identification  as  a 
CLIN,  each  CPCI  must  also  be  represented  by  an  Exhibit  CLIN  and  by  a CDRL 
entry  (see  Section  C2. 7)  defined  by  (0)  DI-E-129,  Computer  So f twa re/Com du ter 
Progran/Computer  Data  Base  Configuration  Itsm(s).  The  CDRL  entry  req;- * rement • 
satisfies  an  ASPR**  that  aims  to  assure  the  Government  Unlimited  Rights 
(discussed  in  Section  C2.5.A)  tc  procured  software  anl  its  documentation 
developed  under  a contract.  Including  software  in  the  CDRL  satisfies  a view 
cf  software  as  a kind  of  data,  while  including  software  among  the  CLINs 


Stated  in  ASPR  9-t>03»  Rights  in  Computer  Software  Acquired  Under 
Contract. 


• • 


T-iW.9.  Rights  in  Data  and  Computer  Software. 


ASPR 


reflects  its  function  as  a mechanism.  Clearly,  the  dual  representations 
should  be  made  consistent. 


C2.2  DeseriPtlon/Soecifications 


This,  Model  Contract  Section  F,  identifies  the  documents  to  which 
the  services  and  supplies  contracted  for  must  conform.  It  also  contains  a 
separate  short  description  of  each  CLIN.-  including  identification  of  any  CPCI 
Versions,  if  the  CLIN  represents  a CPCI.  To  facilitate  reference,  the  CLIN 
description  should  also  include  the  PBC  of  the  corresponding  Preliminary  CWBS 
Element,  or  identify  the  corresponding  SON  paragraph  by  paragraph  number  or 
PBZ.  The  Description/Specification  should  not  be  confused  with  the 
Specifications  (e.g.,  the  System  Specification),  which  are  contained  in  RFP 
Volume  III,  or  if  classified  in  RFP  Volume  IV. 


Tne  ccnfcnsar.ce  dcc-jsenta  listed  in  fection  F should  include  all 
applicable  specifications  ar.d  the  SON,  and  may  specify  inclusion  of  the  final 
negotiated  version  of  the  contractor 's  technical  proposal.  Including  the 
proposal  in  the  negotiated  contract  is  nontally  desirable;  it  can  make  a 
contract  clearer  than  one  union  lacks  the  proposal.  However,  proposal 
inclusion  say  introduce  hidden  inconsistencies  and  undesirable  constraints. 
These  should  be  minimized  by  careful  review  and  modification  of  the  proposal, 
since  they  can  otherwise  cause  controversy  during  development.  Such 
controversy  can  occur  despite  an  appropriate  Order  of  Precedence  (see  Section 
Z2. 5-1)  tnat  allows,  the  Specifications,  etc.,  to  override  conflicting  proposal 
provisions^  If  the  Offerer's  technical  proposal  is  included,  a special 
provision  describing  its  effect  should  be  included  in  Model  Contract  Section  J 
(see  guidebook  Section  C2-5). 

Clearly,  inconsistencies  between  the  CLIN  descriptions  and  the 
corresponding  SON  »ask  descriptions  should  be  minimized.  Consistency  is  most 
likely  if  the  CLIN  descriptions  are  prepared  with  minimal  changes  from  the 
appropriate  paragraphs  of  the  final  SOW. 


C2 . 3 Deliveries  or  Performance 

This,  Model  Contract  Section  H,  prescribes  for  each  CLIN  (or  CPCI 
Version)  a desired  delivery  date  (for  a deliverable  item)  or  Period  of 
Performance  (for  a service).  A Period  of  Performance  can  be  defined  to  begin 
or  to  end  at  a fixed  date.  A1 tematively,  some  Periods  of  performance  can  be 
defined  relative  to  others,  or  to  other  events.  Section  K is  often  called  the 
Delivery  Schedule.  It  is  typically  a major  iter,  of  negotiation. 


Groups  of  supplies  and  services  wanted  at  different  times  should 
normally  t*:  defined  as  separate  CLINs  in  Model  Contract  Section  E.  However, 
note  that  a separate  delivery  date  should  be  ertablished  in  the  Delivery 
Scnedule  for  each  Version  of  a CPCI  which  is  a single  CLIN,  for  the  reasons 
discussed  :r.  Section  C 2.?.'.  Tc  avoid  possibl*  inconsistency,  SON  definitions 
of  tasks  shruld  reference  the  Celivery  Schedule,  rather  than  incorporate 
delivery  dates  and  Periods  of  Ferfomar.ee.  Similarly,  the  special  CDPL  entry 
representing  each  CPCI  see  Ce.tior.  ZZ.'.Z  must  reference  the  Celivery 
I>  ned-le  ft-'  tr.e  iPTI  s delivery  date’s  . 


C2.4  Inspection  and  Acceptance 


This,  Model  Contract  Section  I,  includes  conditions  governing  the 
delivery  and  acceptance  of  the  CLIhs  and  other  deliverables  (e.g.,  CPC  I 
Versions).  These  conditions  should  include  F.O.B.  point,  plus  office(s)  and 
site(s)  for  each  delivery.  For  each  CPC I Version,  the  conditions  should  also 
include  the  Version  identification  and  the  corresponding  TDD,  plus  the  number 
of  copies  of  the  Version  and  the  nunber  of  copies  of  its  VDD,  to  be  delivered 
to  each  site. 

To  minimize  deliveries  of  defective  software,  each  Version  should  be 
appropriately  tested  before  delivery,  as  a condition  of  its  acceptance.  If 
the  Version  incorporates  extensive  modifications,  and  if  it  is  to  be  used 
operationally,  a complete  FQT  should  be  required . The  applicable  testing 
should  be  specified  in  the  CPCI's  Test  Plan  and  Test  Procedures,  normally 
prepared  and  approved  after  contract  award.  Model  Contract  Section  H should 
reference  the  Test  Plan  and  Test  Procedures.  Mote  that  the  Test  Plan  and  Test 
Procedures  for  a CPCI  to  be  delivered  in  Versions  aust  accurately  reflect  each 
Version's  definition.  A certificate  of  satisfactory  testing  should  accompany 
each  Version  on  delivery.  The  Model  Contract  should  define  the  fora  of  these 
certificates  and  the  signatures  required,  normally  DD  Fora  250  is  used. 

C2-5  Special  Provisions 

This,  Model  Contract  Section  J,  typically  contains  important 
provisions  not  covered  by  standard  contract  clauses.  Among  these  are: 
identification  of  the  type  of  contract  (e.g.,  CFIF,  CPFF),  a statement  giving 
the  Procuring  Contracting  Officer  or  his  designee  the  sole  right  to  direct 
contractor  effort,  definition  of  any  contract  options,  the  Order  of 
Precedence,  conditions  governing  contractor  use  of  GFP , and  definition  of 
relationships  among  Governaent  participants  and  contractors. 

If  the  contract  is  to  provide  less  than  Uni  ini ted  Government  Rights 
to  data  ( i . e . , documents  and  computer  programs)  produced  under  the  contract, 
these  rights  will  be  set  forth  in  Special  Provisions.  If  any  of  these  topics 
(e.g.,  Unlimited  Government  Rights  to  Data) , is  fully  covered  by  a standard 
clause,  the  General  Provisions  (see  Section  C2.6)  instead  of  the  Special 
Provisions  will  contain  that  clause. 

To  permit  its  enforcement,  each  contractor-prepared  plan  (e.g.,  the 
CPI?,  the  SEKP)  to  be  followed  must  be  identified  in  the  Special  Provisions 
and  included  among  the  Attached  Documents  of  the  negotiated  contract.  A SOW 
paragraph  must  provide  for  updating  each  such  plan  (see  Section  2.1.7)  »nd  a 
CDRL  entry  aust  call  for  preparation  of  its  revisions  (see  Section  C2.7). 

C2.5.1  frrder  of  Precedence.  The  Order  of  Precedence  defines  the  way  any 
inconsistencies  among  parts  of  the  contract  (including  documents  incorporated 
cy  reference)  shall  be  resolved.  That  is,  if  provisions  of  two  Sections  or  a 
contract  conflict,  the  provision  In  the  higher  precedence  Section  will  be 
cee-.*d  correct.  The  usual  Order  of  Precedence  is:  the  Schedule,  General 
previsions,  the  Specif ications,  the  SOW  ( see  Section  2‘,  and  the  contractor  s 
.. — coal  if  included  it:  the  contract  . Idfter  Orders  cf  Precedence  are 


permissible.  For  example,  the  System  Specification  should  normally  be  given 
higher  precedence  than  any  Segment  Specification,  and  a Segment  Specification 
higher  precedence  than  the  corresponding  Computer  Program  Development 
Specifications,  to  a?~.ure  that  any  conflicts  in  specifications  are  resolved  in 
favor  of  higher-level  requirements . Mote  that  the  Order  of  Precedence  will 
not  resolve  conflict  within  any  of  its  defined  categories.  For  example,  the 
Order  of  Precedence  could  not  decide  between  two  conflicting  paragraphs  of  the 
same  SOU,  unless  these  paragraphs  were  distinguished  by  the  Order  of 
Precedence. 

While  a defined  Order  of  Precedence  is  an  essential  backup  device  to 
resolve  conflict,  every  effort  should  be  made  to  prevent  conflict. 

Referencing  other  documents  for  information  that  is  well-defined,  instead  of 
paraphrasing  or  summarizing  it,  is  one  valuable  conflict-prevention  technique. 
This  also  reduces  the  need  for  concurrent  updating  to  reflect  changes.  For 
example,  the  SOU  should  reference  Specification  paragraphs  rather  than 
redescribe  software  to  be  developed.  If  a referenced  specification  no  longer 
precisely  describes  what  is  wasted,  it  should  be  updated  rather  than 
incorporate  the  changes  (or  conflicting  requirements)  in  the  SOW.  v 

C2-5-2  GoYemcent-Furnished  Property  tGFP).  The  GFP  provisions  should 
identify  ail  items  of  GFP  {including  Government-furnished  software  or  computer 
time)  to  be  used  by  tne  contractor  as  development  aids.  They  should  also 
designate  all  G Ft  witn  which  equipment  or  software  to  be  developed  under  the 
contract  must  interface.  In  additicn,  they  should  specify  the  pertinent 
documentation  to  be  made  available  and  state  when,  where  and  under  Uiat 
conditions  the  contractor  can  use  each  GFP  item.  For  example,  the  GFP 
provisions  should  include  any  Government-owned  Operational  Executive  software 
with  which  contractor-developed  Application  Software  will  interface.  Great 
care  should  be  taken  to  identify  GFP  precisely,  and  to  define  correctly  its 
interfaces  with  equipment  or  software  to  be  developed  under  the  contract. 
Otherwise,  errors  and  omissions  in  GFP  definition  nay  support  contractor 
claims  against  the  Government . 

C2.5.3  Working  Relationships.  The  Special  Provisions  should  define  the 
working  relationships  of  two  or  sore  contractors  who  must  interface  their 
products  or  tasks.  For  exaaple,  if  the  acquisition  involves  Independent 
Validation  and  Verification  {¥&¥),  the  V*V  contractor's  role  should  be  spelled 
out  by  enabling  clauses  in  the  development  contractor's  contract,  and  vice 
versa.  Similarly,  if  Government  contract  management  includes  FCRC  (e.g., 
MITRE)  support,  the  Special  Provisions  should  specify  the  intended  FCRC- 
contractor  relationships  (e.g.,  by  including  one  of  the  three  optional 
standard  MITRE  enabling  clauses).  Finally,  the  Special  Provisions  should 
permit  Government  visibility  (vs.  control)  into  any  subcontractors' 
activities.  For  exaaple,  the  Special  P rr  sxocs  should  direct  a prime 
contractor  to  notify  the  Government  of  important  meetings  (e.g.,  PDRs,  CDRs, 
fQZs ) involving  his  subcontractors.  These  previsions  should  grant  the 
Government  the  right  to  attend  all  such  meetings.  Also,  the  CDRL  should 
specify  contractor  delivery  tc  the  Government  of  the  most  pertinent 
s u teen t rac  to r-p ro 0 ur ed  doc  user. ts . 


C2-5-4  Government  Rights  to  Data.  Inadequate  provisions  for  Government 
rights  to  data  produced  under  a contract  have  caused  trouble  and  expense  in 
several  acquisitions.  The  contract  should  thus  specify  the  type  of  rights 
(i.e.,  Unliaited,  Liaited,  or  Restricted)  desired  for  each  group  of  data. 

As  a rule  the  contract  should  grant  the  Government  Unliaited  Rights  to 
all  documents  and  software  specified  in  the  CURL.  ASPR  7-104.9  defines 
Unliaited  Rights  to  include  the  rights  of  use.  disclosure,  duplication  or 
distribution,  for  any  purpose,  by  Government  personnel  or  others. 

ASPR  7-104.9  also  defines  Liaited  Rights  and  Restricted  Rights.  The 
Government  should  negotiate  Liaited  Rights  to  other  contractor-owned 
documents,  and  Restricted  Rights  to  contractor-owned  software,  if  needed  to 
facilitate  system  development  or  aanageaent  under  the  contract.  For  exaaple. 
Restricted  Rights  to  the  contractor-owned  coapilers,  diagnostics,  and  other 
Support  Software  to  be  used  in  the  systee  during  any  phase  of  the  Acquisition 
Life  Cycle,  plus  Lisited  Rights  to  their  docusentation , are  noraally  essential 
to  effective  Government  use  and  maintenance  of  that  software.  Again,  Liaited 
Rights  to  use  certain  contractor-owned  scenarios  developed  under  a non- 
Governaent  contract  sight  be  negotiated  to  support  tests  under  the  planned 
contract.  However,  any  data  needed  for  other  current  or  future  systeas  should 
be  provided  under  the  CORL,  with  Unlisited  Rights  if  econoeically  feasible, 
considering  all  intended  uses.  In  negotiating  Liaited  Rights  and  Restricted 
Rights,  Governnent  representatives  should  try  to  avoid  restrictions  that  could 
nasper  the  data's  appropriate  use  at  any  tiae  during  the  system's  Acquisition 
Life  Cycle.  Since  the  effects  of  restrictions  car.  be  subtle,  each  proposed 
restriction  should  be  discussed  with  the  Governnent 's  technical  managers, 
including  the  Software  Director. 

Before  any  data  is  procured,  the  contractor  should  certify  that  he  has 
not  previously  delivered  such  data  (under  another  contract)!  Also,  the 
Government  should  independently  check  (e.g.,  by  search  of  the  Defense 
Documentation  Center  (DDC)  and  the  Air  Force  Logistics  Command  ( AFLC ) Software 
Library)  tf*at  it  does  not  already  own  such  data  or  rights  to  thee.  The 
Government  should  also  check  to  be  sure  that  the  data  is  not  in  the  public 
domain! 

The  contract  should  also  allow  Governnent  access  to  all  unofficial 
documents  (e.g.,  nenoranda,  design  sketches,  worksheets,  non-deliverable 
versions  of  coding)  produced  through  any  effort  exerted  under  the  contract. 

The  contractor  should  be  required  to  identify  all  such  infonaai  documentation 
in  a CCRL-defined  Data  Accession  List  deliverable  sonthly.  DI-A-3027,  Data 
Accession  List/ Internal  Data,  defines  the  Data  Accession  List.  A SOW  task 
should  prescribe  Data  Accession  List  generation.  These  provisions  should 
grant  to  designated  Governnent  personnel  (e.g.,  those  aonitoring  software 
development)  the  right,  on  deaand , to  inspect,  review  or  copy  any  documents 
identified  in  a Data  Accession  List,  provided  the  use  and  further 
di3senination  of  tr.e  information  thus  obtained  is  lisited  to  legitimate 
purposes  of  this  acquisition. 


C2.6  General  Provisions 


This,  Model  Contract  Section  L.  typically  lists  the  standard  ASPR 
contract  clauses  incorporated  by  reference  In  the  Model  Contract.  These 
clauses  give  the  Government  important  rights ; e.g. , to  change  or  terminate  a 
contract,  to  approve  subcontracts,  is  an  example.  Table  C-2  depicts  the  set 
of  ASPR  clauses  in  the  Model  Contract  of  a recent  RFP.  However,  this  example 
should  not  be  used  as  a aodel,  since  the  appropriate  set  of  ASPR  clauses  and 
their  dates  may  differ  significantly  among  acquisition  programs.  The  General 
Provisions  also  include  other  standard  clauses  (e.g..  Restrictions  on 
Printing,  Release  of  Information)  or  incorporate  then  by  reference.  Finally, 
Section  L includes  any  required  and  approved  tailoring  of  standard  clauses. 

C2-7  Contract  Data  Requirements  List  (CDRL) 

The  CDRL  is  one  of  several  Model  Contract  attachments . Others,  such 
as  the  Specifications,  the  Preliminary  CMBS  (see  Section  At. A)  and  the  SOM, 
are  included  in  RFP  Volume  III,  or  in  RFP  Volume  IV  if  classified. 

The  CDRL  defines  the  documentation  and  the  software  storage  media 
deliverable  under  the  contract.  These  are  termed  Data  Items.  All  instances 
cf  each  Data  Item  ire  defined  in  a sequence-numbered  CDRL  entry.*,  •• 
Primarily,  each  Model  Contract  CDRL  entry: 

a.  specifies  the  Dat;.  Item's  title  (and  subtitle,  if  any); 

b.  identifies  the  Data  Item  Description  (DID)  that  prescribes 
the  Data  Item's  content  and  format,  and  indicates  whether 
this  DID  is  modified; 

c.  specifies  the  one  or  more  SOM  or  ASPR  paragraphs  that 
call  Ter  the  Data  Item's  preparation; 

d.  defines  how  often  the  Data  Item  must  be  delivered  (e.g., 
once  monthly) ; 

e.  specifies  (e.g,.  for  periodic  reports)  the  dates  as 

of  which  each  version  of  the  Data  Item  should  be  prepared; 

f.  states  the  dates  of  the  Data  Item's  initial  submission 
and  of  any  subsequent  submissions; 


• ASPR  20-306,  Data  Item  Sequence  Mumbcrimt  System,  prescribes  the 
assignment  of  sequence  numbers  to  CDRL  entries. 

••  until  recently  all  CDSL  entries  were  prepared  using  a standard  form,  DC 
Fora  1*23.  and  associated  preparation  instructions.  Currently,  DD  Form 
*42 5 is  being  supplanted  by  new  forms  for  which  preparation  instructions 
are  undergoing  review 


Table  C-2 

AW  EXAMPLE  SET  OF  ASPR  CLAUSES 


Beference  ASPR 

er Paragraph 


Clause  Title 


Date  of 
Clause 


1. 

7-103-1 

Definitions 

1962 

Feb 

2. 

7-103-2 

Changes 

1958 

Jan 

3. 

7-103-3 

Extras 

1949 

Jul 

4. 

7-103-4(a) 

Variation  in  Quantity 

1949 

Jul 

5. 

7-l03-5(a) 

Inspection 

1958 

May 

6. 

7-103- 5(b) 

Variation  of  Above  Clause  #5 
for  Incentive  Contracts  Only 

1962 

*. 

7- 

7-103.6 

Title  and  Risk  of  Loss 

1968 

Jun 

a. 

7-103.7 

Payments 

1958 

Jan 

9. 

7-103.8 

Assignment  of  Claias 

1962 

Feb 

10. 

7-103-9 

Additional  Bond  Security 

1949 

Jul 

ii. 

7-103- 10(a) 

Federal,  State,  and  Local  Taxes 

1971 

Nov 

12. 

7-103-11 

Default 

1969 

Aug 

13- 

7-103- 12(a) 

Disputes 

1958 

Jan 

!*. 

«,  »»««w  » m m w 

• 

wv 

15- 

7-103-14 

Discounts 

1968 

Jun 

16. 

7-103- 16(a) 

Contract  Work  Hours  and 
Safety  Standards  Act  - 
Overtime  Compensation 

1971 

Nov 

17. 

7-103.17 

Walsh-Healey  Public  Contracts  Act 

1958 

Jan 

18. 

7-103. 18(a) 

Equal  Opportunity 

1972 

Aug 

19. 

7-103-19 

Officials  Wot  To  Benefit 

1949 

Jul 

20. 

7-103-20 

Convenant  Against  Contingent 
Fees 

1958 

Jan 

21. 

7-i03-2Kb) 

Termination  for  Convenience 
of  the  Government 

1974 

Oct 

22. 

7-103.22 

Authorization  and  Consent 

1964 

Mar 

23- 

7-103-23 

Notice  and  Assistance 
Regarding  Patent  and  Copy- 
right Infringement 

1965 

Jan 

24. 

7-103-24 

Responsibility  for  Inspection 

1968 

Sep 

25. 

7-103.26 

Pricing  of  Adjustments 

1970 

Jul 

26. 

7-103-27 

Listing  of  Employment  Openings 

1973 

Sep 

27. 

7-104.3 

Buy  American  Act 

1984 

May 

28. 

7-104.4 

Notice  to  the  Government 
of  Labor  Disputes 

1958 

Sep 

29. 

7-104.6 

Filing  of  Patent  Applications 

1969 

Dec 

30. 

7-104. 9(a)(b) 

Rights  in  Technical  Data 
and  Computer  Software 

1974 

Nov 

31- 

7-104. 9(h) 

Technical  Data  - Withholding 
cf  Payment 

1974 

Apr 

32. 

7-104.9(1) 

Identification  of  Technical 
Data 

1972 

Apr 

33- 

7 - 1 04 . 9 ' r. : 

Data  Peq-irecrerts 

iQf  2 

Apr 

Table  C-2  (Continued) 


Reference 

ASPR 

Date  of 

lumber 

Paragraph 

Clause  Title 

Clause 

3*. 

7-104. 9(p) 

Restrictive  Harkings  on 
Technical  Data 

1974  Apr 

35. 

7-104.12 

Military  Security  Requirements 

1971  Apr 

36. 

7-104. 14(a) 

Utilization  of  ^all  Business 
Concerns 

1958  Jan 

37. 

7-104.15 

Examination  of  Records  by 
Comptroller  General 

1971  Mar 

36. 

7-104.16 

Gratuities 

1952  Mar 

39- 

7-104.17 

Convict  Labor 

1974  Apr 

to. 

7-104. 18 

Priorities,  Allocations  and 
Allotments 

1974  Apr 

*1. 

7-104. 20(a) 

Utilization  of  Labor  Surplus 
Area  Concerns 

1970  Jun 

*2. 

7-104. 21(a) 

Limitation  on  Withholding  of 
Payaents 

1958  Sep 

*3- 

7- 504. 23(a) 

Subcontracts 

iy?4  Apr 

44. 

7-104. 24(a)(c) 

Government  Property  (Fixed 
Price) 

1968  Sep 

45. 

7-104.32 

Duty-Free  Entry  - Canadian 
Supplies 

1971  Feb 

46. 

7-104. 36(a) 

Utilization  of  Minority 
Business  Enterprises 

1971  Jtov 

47. 

7-104.38 

Required  Sources  for  Miniature 
and  Instrument  Dali  Bearings 

1971  Jul 

48 

7-104.39 

Interest 

1972  Hay 

49. 

7-104. 41(a) 

Audit  by  Department  of 
Defense 

1974  Apr 

50. 

7-104. 45(a) 

Limitation  of  Liability 

1974  Apr 

5U 

7-104.62 

Material  Inspection  and 
Receiving  Report 

1969  Dec 

52. 

7-104.68 

Marking  of  Shipments 

1968  Jun 

53- 

7-104. 77(f) 

Government  Delay  of  Work 

1963  Sep 

54. 

7-104.82 

Payment  of  Interest  on 
Contractors'  Claims 

1972  May 

55. 

7-105. 3(c) 

Stop  Work  Orcer 

1971  Apr 

56. 

7. 105.4 

Report  of  Shipment  (Repship) 

1968  Jun 

57. 

7-104.9(o)(1) 

Warranty  of  Technical  Data 

1974  Oct 

56. 

7-104. 29(a) 

Price  Reduction  fer  Defective 
Cost  or  Pricing  Data 

1970  Jan 

59. 

7-104.40 

Conpetitior.  in  Subcontracting 

1962  Apr 

60. 

7-104. 42(a) 

Subcontractor  Cost  or 
Pricing  Data 

1970  Jan 

6i. 

7_iC-4.44>; , i; 

Vai*;e  engineering  Incentive 

19?4  Apr 

c2. 

r.C.B.  Destination 

i960  Apr 

Table  C-2  (excluded} 


deference 

ksn 

fragcuii 

Clam  Title 

63- 

7-104.75 

Diversion  of  Shipnent  Under 
F.O.B.  destination  Contracts 

64. 

7-104.76 

F.O.B.  Destination  - 
Evidence  of  Shipnent 

65. 

7-104.83 

Cost  Accounting  Standards 

66. 

7-104.86 

■otif ici  tion  of  Qianges 

67. 

7-104.89 

Engineering  Change  Proposals 

68. 

7-104.90 

Change  Order  Accounting 

69. 

7-1C5.2 

Appi^vel  of  Contract 

Date  of 
Clause 

1971  Hot 

1968  Jua 

197*  Jan 
Undated 
Undated 
Undated 
19*9  Jul 
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g.  contains  the  distribution  list  (i.e.,  the  Data  I tea's 
recipients,  the  number  of  copies  each  should  receive, 
and  the  total  number  of  copies);  and 

h.  states  any  requirement  for  Government  review  and  approval 
of  the  data  item  before  its  final  publication  and 
acceptance. 

Each  Model  Contract  CDRL  entry  also  includes  blank  fields  for  Offerer 
estimates  of  the  Data  Item's  price  and  number  of  pages.  The  price  must  be 
based  on  the  Offerer's  estimates  of  his  costs  to  develop,  reproduce,  and 
distribute  the  Data  Item,  over  and  above  the  costs  he  would  otherwise  occur  if 
the  Data  Item  were  rot  required.*  The  contractor's  proposal  must  provide  this 
information.  (Usually  the  RFP  states  that  a proposal  that  lacks  these  price 
esciaat.es  say  be  rejected  as  non-res  pensive) . 

1 Data  Item's  title  (and  subtitle,  if  any)  must  agree  with  those  in 
the  SOW  paragraph(s)  prescribing  its  preparation,  in  order  to  avoid  ambiguity. 
To  maximize  SOW /CDRL  consistency,  a proposed  CDRL  entry  should  be  prepared 
for  each  Data  Item  (or  set  of  identically  defined  Data  Items)  planned  to 
result  from  the  effort  of  each  SOW  paragraph.  The  same  CDRL  entry  may  define 
more  than  one  Data  Item  (e.g.,  several  CPC Is ' Computer  Program  Product 
Specifications)  provided  that  CDRL  entry  correctly  defines  them  all.  These 
CDRL  entries  and  the  SOU  snould  be  developed  in  parallel,  by  the  same  persons. 
Preparation  of  proposed  CDRL  entries  is  facilitated  by  using  AFSC  Form  40, 
explained  in  AFSCR  310-1.  This  provides  room  both  for  outlining  and  for 
justifying  the  CDRL  entry.  The  latter  is  necessary  because  each  proposed  Data 
Item  is  subject  to  formal  challenge  on  grounds  of  cost-effectiveness  by  a Data 
Requirements  Review  Board,  per  AFR  3 1 0— 1 , Management  of  Contractor  Data. 

As  discussed  in  Section  C2.1.2,  each  CPCI  must  be  represented  by  ar. 
Exhibit  CLIN  and  by  a special  CDRL  entry  as  well  as  by  a normal  CLIN.  This 
special  CDRL  entry  must  not  specify  delivery  dates.  Instead,  it  must 
reference  the  Delivery  Schedule.  When  several  successive  Versions  of  a CPCI 
are  to  be  delivered,  a normal  CDRL  entry  should  prescribe  the  corresponding 
VDDs  (see  Section  C2.1.D  and  a special  CDRL  entry  should  specify  the 
corresponding  storage  media.  (See  Section  2.1.2). 

Each  enforceable  contractor-prepared  plan  (e.g. , the  CP  DP , the  SEJS*) 
to  be  delivered  or  modified  under  the  contract  must  be  defined  by  a CDRL 
entry. 

Uh»rever  a modified  DID  prescribes  a CDRL  entry's  form  and  content, 
tne  DID  identification  must  indicate  this  (e.g.,  by  appending  VH*  to  the  DI 
number).  The  modifications  themselves  must  be  stated  in  the  CDRL  entry 
itself,  or  on  backup  sheets  attached  to  the  CDRL. 

CDRL  preparation  »nd  DID  modification  are  further  described  in  ESD- 
7H_76-159.  An  Air  Force  Guide  to  Software  Documentation  Requirements . in  AFSCR 
310-1  (including  LSD  Supplement  1),  and  in  AFR  31C-1. 


• jPZ  Forz  *97*  1— rc-*rl.  Ir.str-cticr.s  far  Completing  DP  Form  LjjLL. 

*2 


C3-  RFP  Tolupe  III  - Attached  Documents  and  References 


The  Attached  Documents  and  References  should  include  the  SOW,  the 
Specifications,  the  appropriate  Project  Suesary  UBS  or  "iiii  j PBS,  the 
Preliminary  CUBS,  their  Dictionaries,  any  applicable  Engineering  Drawings,  DD 
Font  25*  (Contract  Security  Classification  Specification) , all  enforceable 
contractor-prepared  plans,  and  any  other  documents  that  provide  background 
inforsation  essential  to  the  particular  contract.  Except  for  the  CDRL  (part 
of  RFP  Volume  II),  these  coaprise  the  usual  contents  of  UCF  ?olu*e  III. 

The  Attached  Documents  and  References  should  also  include  copies  of  any 
unique,  aodified  or  Research  and  Developeent  (RAD)  DIDs  referenced  in  CDRL 
entries.  Other  referenced  documents  (e.g.,  the  ASPR  clauses,  silitary 
standards)  which  Offerers  nay  be  presorted  to  possess,  or  which  can  be  obtained 
from,  standard  sources,  are  nonsally  caitted  from,  the  RFP.  Whenever  the  RFP 
on its  a referenced  dccueent.  Offerers  should  be  given  rapid  access  to  it  on 
request,  subject  to  ccepliance  with  security  regulations.  An  Offerer's 
Library,  if  established  for  the  acquisition,  can  satisfy  this  need. 

Appendix  A describes  UBSs  and  their  Dictionaries.  Sections  2 and  3 treat 
SCW  requirements . Sections  C3-1  - C3-2,  respectively,  discuss  the 
Specifications,  Engineering  Drawings,  and  DD  Fore  25*. 

C3- 1 The  Specifications 

Sot  to  be  confused  with  the  Description/Specifications  (see  Section 
C2.2),  the  Specifications  (e.g.,  the  Svstes  Specification)  are  the  RFP 
attachments  that  define  the  system  and  its  parts.  Thus,  the  Specifications 
are  an  essential  part  of  a SF?  for  a contract  that  includes  software 
developaent,  since  the  effort  contracted  for  is  best  defined  relative  to 
Specification  provisions. 

A RFP  say  include  software-related  specifications  of  several  levels 
and  types*,  depending  on  the  contractual  approach,  on  the  Acquisition  Life 
Cycle  Phase  (see  LC EG,  Sections  2-5),  and  on  the  types  of  work  and  product 
being  contracted  for.  Table  C-3  depicts  the  structure  and  contents  of  the 
•ore  important  types  of  software-related  specifications.  LCEG,  Appendix  A 
sussarizes  thes. 

C3-2  Engineering  Drawings 

These  typically  describe  equipeent  (e.g.,  portions  of  a grapnical 
display  device),  a site  (e.g.,  a command  post  layout,  a coaputer 
installation),  or  interfaces  (e.g.,  between  systems).  Such  Engineering 
Drawings  are  necessary  for  the  developeent  of  any  software  that  uust  interface 
with  equipeent,  the  persons  operating  it,  or  other  software,  unless  the 
interface  is  otherwise  precisely  defined  (e.g.,  in  Coaputer  Program 
Developaent  Spec \ f icat 10ns ) . See  ESD-Tfi-76- 159  for  further  details. 


HIL-S-c 2*9D , Soec. f .cations , Types  and  Fores,  and  MIL-STE-$9C,  paragraphs 
4 briefly  define  t-.e  different  preserved  specification  types. 

Ewl-Tr-'t- 7 a.s:  c.si.soes  several  types  :f  specification 


Table  <>  » 

OUTMNKS  OK  SOKTWAW.-KEUTE0  SKECt riCATtOK  TYKES 


Tabl*  <-l  front lnu»d) 


f 5 


Storage  allocation 


Tab  la  <:-i  (Concludad) 


9? 


• tc.  (tf  any)  (i*  any)  <lf  my) 

*P~a7  KIU-STO- *to7  Appandl*  I.  and  «L-STt>-aJ(U»An , Appandiv  III 
••Par  HIL-«Tt>-*90,  Appandlx  VI,  and  MlL-ITO-AaXUaAP) , paragraph  AO,  4, 

#Par  K1U-STD-490,  Appandlx  XX 1 1 . and  MM^m-ARHUtAr) . paraarath  AO.  3 


C3-3  Cob  tract  Security  film  lficatloa  Pacification 


Coes  is  tine  of  IS  For*  25*  plus  possible  attachnents,  this  states  the 
security  requir— eats  applicable  to  the  coo tract.  For  ezaaple,  it  prescribes 
the  level (s ) of  security  clearance  required  of  coetrector  personnel  writing  on 
the  contract. 

c*.  fff  Klims.  11  - flmttlM  firti  aUHJtt 

Any  classified  attachments,  or  other  classified  provisions  of  toe  IFF, 
will  be  contained  in  Volute  IV,  and  referenced  froa  their  usual  places.  For 
exaaple,  Voluae  IV  would  contain  a classified  Systsa  Specification,  any 
claasified  Sagaent  Specifications,  and  any  classified  Developaent 
Specifications  or  Product  Specifications. 
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USX  OF  ABBSE¥IATIO*S 


Abbreviation 


Definition 


ACI 

ADP 

AfLC 

AFSC 

ASPS 

ATC 

BA/PA 

BITE 

CCB 

CDS 

CDSL 

Cl 

CLIM 

CMP 

CPAF 

CPC 

CPCI 

CPDP 

CPFF 

CPIF 

CPMF 

CRISP 

CUBS 

DCP 

DDC 

DID 

DoD 

DODD 

DODI 

DSASC 

DTAE 

ECO 

ECP 

ESD 

FA 

FCA 

FCI 

FCRC 

FF? 

F0T4E 

FPIF 

FQR 

FQT 

GFP 

IFF? 

IOTAS 

LCC 


Allocated  Configuration  Identification 

Automated  Data  Process!^ 

k!  r Force  Logistics  Co— and 

Air  Force  System*  Co— and 

Armed  Services  Procurement  Segulatlona 

Air  Training  Co— anl 

Budget  Autborizatioi/Frogr—  Authorization 

Built-in  Test  Equipment 

Configuration  Control  Board 

Critical  Design  Review 

Contract  Data  Requirements  List 

Configuration  Item 

Contract  Line  Item  or  Subline  Item 

Configuration  Management  Plan 

Cost  Plus  Award  Fee 

Computer  Program  Component 

Computer  Program  Configuration  Item 

Computer  Program  Development  Plan 

Cost  Plus  Fixed  Fee 

Cost  Plus  Incentive  Fee 

Computer  Program  Maintenance  Facility 

Computer  Resources  Integrated  Support  Plan 

Contract  Work  Breakdown  Structure 

Decision  Coordinating  Paper 

Defense  Documentation  Center 

Data  Item  Description 

Department  of  Defense 

Department  of  Defense  Directive 

Department  of  Defense  Instruction 

Defense  Systems  Acquisition  Review  Council 

Development  Test  and  Evaluation 

Engineering  Change  Order 

Engineering  Change  Proposal 

Electronic  Systems  Division 

Functional  Area 

Functional  Configuration  Audit 
Functional  Configuration  Identification 
Federal  Contract  Research  Center 
Fine  Fixed  Price 

Follow-on  Operational  Test  and  Evaluation 
Fixed  Price  Incentive  Firm 
Formal  Qualification  Review 
Formal  Qualification  Test 
Government-Furnished  Property 
Ins* ructions  for  Proposal  Preparation 
Initial  Operational  Test  and  Evaluation 
Life  Cycle  Cost 
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3iigpipSS|§ScSge|?s3i35gg2gS?| 


ifcteiiauan 

LCEC 


UCf 

V4V 

FDD 

V£ 

FEC P 
MBS 


LIST  OF  AB8REVIAT10RS  (Ctoneluied) 

Definition 

Artmrg  Acquisition  Ihnniat  Gu^^rv^. 

Life  Cycle  Events 

(*>e  rational  Teat  and  Evaluation 

Prog rm  Breakdown  Code 

Program  Breakdown  Structure 

Physical  Configuration  Audit 

Procuring  Contract!^  Officer 

Preliminary  Design  Review 

Prog ran  Manager 

Prog ran  Management  Directive 

Program  Management  Plan 

Preliainary  Qualification  Test 

Prograc  Office 

Programing  Support  Library 

Program  Summary  Work  Breakdown  Structure 

ftality  Assurance 

Research  and  Development 

Request  for  Proposal 

Supplemental  Agreement 

Specification  Change  Roti.ee 

System  Design  Review 

System  Engineering  Management  Plan 

Statement  of  Work 

Systec  Requirements  Review 

Source  Selection  Authority 

Source  Selection  Advisory  Council 

Source  Selection  Evaluation  Board 

Source  Selection  Plan 

Scientific  and  Technical  Information 

Test  and  Evaluation 

To  be  Determined 

Test  A Evaluation  Master  Plan 

Technical  Performance  Measurement 

Uniform  Contract  Fonaat 

Validation  and  Verification 

Version  Description  Document 

Value  Engineering 

Value  Engineering  Change  Proposal 

Work  Breakdown  Structure 
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MFAITHUT  OF  D8FEBSE  PWUCATIORS 

ASTI  Section  IX*» 

Part  6 

PSP*  Section  XI*» 

Part  3 

TO-3 

1 ioreaber  1975 


Rights  in  Computer  Software  Acquired 
Oader  Contract 

Contract  Exhibits  and  Data  Itaa 
Sequence  Runbcriag  Spates 

DoD  Authorised  Data  List,  Index  of 
Data  Xtea  Descriptions 


MILITARY  SPECIFICATIORS  ADD  STAIOAXDS 


WUS-52779(AD) 

5 April  197* 

WL-S-83%90 
30  October  1968 

MIUSTD-480 
30  October  1968 

MIL-STD-*83(USAF) 
including  Rotice  1 
1 June  1971 

ML-STD-A90 
including  Change  2 
18  Hay  1972 


Software  Quality  Assurance  Progr 
Requireaents 

Specifications,  Types  and  Fores 


Configuration  Control  - Engineering 
Changes,  Deviations  and  Malvern 

Configuration  Manageaent  Practices 
for  Systeas,  Equipaent,  Munitions, 
and  Coaputer  Progress 

Specification  Practices 


mUSTD-A99A(0SAF) 

1 Hay  197* 

MIL- STD- 881 A 
25  April  1975 

MIL-STD-1521 (USAF) 
including  Change  2 

2 January  1975 


Engineering  Manage 


Work  Breakdown  Structures  for  Defense 
Materiel  Iteas 


Technical  Reviews  and  Audits  for 
Systeas,  Equipaent,  and  Coaputer 
Progress 


KIL-V-38352  Value  Engineering  Prog ran  Requireaents 

including  Aaendaent  1 
20  January  1965 

AIR  FORCE  AMD  SUBORDINATE  COMMA!©  DIRECTIVES 

AF  ASPS  Suppleaent  Procureaent  Plan 

1-2100.50 


101 


AFP  70-15 
16  April  1976 


ursnaczs  (Continued) 


Source  Selection  Policy  and  Procedures 


AF1  60-45 
26  March  1971 
AFSC  sup.  1 
4 February  1976 
ESD  Sup.  1 

10  tee.  1971 

AF4  3 1C— 1 

Including  Change  1 
14  June  1971 

AFP  8 CO-14,  fol.  II 
26  Sep tee  her  1975 

AFSCM  173-4 
24  goreeber  1972 

AFSCP  70-4 

30  May  1975 

AFSCP  800-6 
18  August  1972 

AFSCP  70-9 
16  August  1974 
ESD  Sup.  1 
20  October  1975 

AFSCP  80-15 

31  December  1974 

AFSCP  310-1 

11  March  1974 
ESD  Sup.  1 

10  October  1974 

ESDP  800-4 
1 December  1975 
including  Change  1 
(to  be  published) 

DATA  ITEM  DESCRIPTIOBS 

DI-A-3027 


DI-E-129 


Distribution  Statements  on 
Technical  Documents 


Management  of  Contractor  Data 


Acquisition  and  Support  Procedures 
for  Computer  Besources  in  Systems 

Program  Breakdown  structure  and 
Codes 

Request  for  Proposal  Preparation 
Guide 

Statement  of  Work  Preparation  Guide 


Source  Selection  Procedures 


RAD  Source  Selection  Policy  end 
Guidance 

Ifenagement  of  Contractor  Data 


Statement  of  Work  preparation  Guide 


Data  Accession  List/ Internal  Data 

Computer  Software/Ccaputer  Program/ 
Computer  Data  Base  Configuration  Itea(s) 
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Joseph  T-  Connolly, 


, ESD-TR-75-9 1 (KTH-3060 
Contract  F1962S-75-C-0001 , The  MITRE  Corporation,  Bedford,  Mass.) 

October  1975- 

S.  8.  Hagan  and  C.  i.  Knight,  An  Air  Force  Guide  for  Monitoring  a 
Reporting  Develoowent  Status.  ESD-TF-75-85  (MTR-3051,  Contract 

F19628-75-C-0G01 , The  MITRE  Corporation,  Bedford,  Mass.},  September  1975 


K.  £.  Bolen, 

E.2J-TR-75-365,  (MTS-3113,  Contract  F19625-76-C-0001 , The  MITRE 
Corporation,  Bedford,  Mass.),  January  1975. 


U.  L.  Scboeffel,  An  Air  Force  Guide  to  Software  Documentation 
Requirements.  ESD-TH-76-159  {MTF-318O,  Contract  F 1 9628-7 6-C-0001 , The 
MITRE  Corporation,  Bedford,  Mass.),  June  1976. 


D.  F.  Peterson. 


Development  aad  Maintenance  Facilities.  (MTR-3330,  Contract  F19628-77-C 
0G~1 , The  MITRE  Corporation,  Bedford,  Mass.),  to  be  published. 


J.  5.  Glore,  Software  Acquisition  Management  Guidebook:  Life  Cycle 
Events . (MTR-3355,  Contract  F19628-77-C-0001 , The  MITRE  Corporation, 
Bedford,  Mass.),  to  be  published. 


tries.  RADC-TR-74-300,  IBM  Corporation, 


Gaithersburg,  Md.,  1974. 


The  Regulations,  Specifications,  Standards  and  DIDs  cited  are  those  in 
effect  when  the  research  for  the  guidebook  was  completed.  Since  that 
time  new  versions  of,  or  changes  to,  soee  of  then  have  been  issued. 
Readers  who  want  to  consult  the  latest  version  of,  or  changes  ♦*>,  a 
reference  should  check  official  sources. 

Also  see  Taole  C-2  for  other  ASPR  clauses  referenced. 


